- Boost - lists.preview.boost.org

Re: [boost] Re: Serialization Formal Review #2
by Robert Ramey 16 Apr '04

16 Apr '04

Thorsten Ottosen wrote: > class gps_position > { > public: > int degrees; > int minutes; > float seconds; > gps_position(){}; > gps_position(int d, int m, float s) : > degrees(d), minutes(m), seconds(s) > {} > }; > I think it should be stated that this is not recommended practice, ie, > this class has a non-trivial invariant and should not have public members. I might add a friend rather than use public. But this small code snipet is used to illustrate the non-intrusive serialization - nothing more. BTW the actual demo programs don't use this. What is the non-trivial invariant here? > A better example might be to use std::pair. > The examples use pointers in arrays and pointers in standard containers. I > think the text shouldstate that this is not recommended; or even better, > throw in a shared_ptr instead. The code in the example is inherently > exception unsafe. > Therefore I also think that container< shared_ptr<T> > should be supported > by default whereas container< T* > is, well, ok if you don't have > exceptions somehow. Writing a good tutorial is much harder than it looks. My main motivation was to introduce one concept at a time. The basic building blocks of serialization are serialization of primitives, pointers and classes - both intrusive and non-intrusive. All the rest is the result of composition of these basic operations. My tutorial reflects this. That's why serialization implementations of standard library components such as pair, vector, etc are described at the end rather than at the beginning - they are not primitive operations. Anyway, I'll consider adding some comments to remind the reader of the intended purpose of he tutorial example. Robert Ramey

3 2

Re: Re: [boost] Serialization Formal Review #2
by Robert Ramey 16 Apr '04

16 Apr '04

Matthias Troyer wrote: > After a few tweaks - which I will report later - I got serialization to > compile on my installation of MacOS X. That is very good news - it's a platform I never tried. Please try and run the bjam test suite as well. > I have a question that does not seem to be addressed in the > documentation: What is the difference betweem save and save_override or > > load and load_override? > demo_fast_binary_archive.cpp uses save_override and load_override but I > could not find it documented? Making a new archive class is described in the section "New Archives - Implementation". The model for an archive class is: ///////////////////////////////////////////////////////////////////////// // class trivial_iarchive - read serialized objects from a input text stream class trivial_iarchive : public boost::archive::common_iarchive<trivial_iarchive> { // permit serialization system priledged access to permit // implementation of inline templates for maximum speed. friend class boost::serialization::load_access; // member template for loading primitive types. // Override for any types/templates that special treatment template<class T> void load(T & t); public: ////////////////////////////////////////////////////////// // public interface used by programs that use the // serialization library // the >> operator template<class T> trivial_iarchive & operator>>(T & t){ boost::serialization::load(* This(), t); return * This(); } // archives are expected to support this function void load_binary(void *address, size_t count); }; So in theory one has to implement the two undefined functions. For each primitive data type, int, float, etc. or any type designated as primitive define a "load" template for function to read them from the file. For each data type that you want to treat specially - rather than allowing the serialization library to do the job - define an overload for the >> operator. That should be all there is too it. The archive classes included in the library are much more elaborate for a number of reasons. Among others these are: a) portability to platforms which fail to support Partial Template Function Ordering. This is what make the load_override functions necessary so that we can apply the "extra argument" work around to simulate PTFO for these platforms. They are not part of an public interface but rather internal artifacts of the implementation of these archives. b) the desire that the archives be templates so that they could work with both char and wchar_t i/o c) the desire to factor out common code for text primitives so that it wouldn't have to be duplicated for xml and text archives. > I can implement an > optimized archive along the lines of demo_fast_binary_archive.cpp, but > extended to also support std::vector, std::valarray, ... Before doing that, I would suggest making a test application with the standard binary archive and try to get some baseline timings. I would be curious to know the results of this. Remember that the point of demo_fast_binary_archive.cpp isn't so much to propose a faster archive ( though it may be ) but really to illustrate how one might derived from one of existing archives to alter its behavior. Robert Ramey

2 1

Re: Re: [boost] Re: [serialization] + [boost.python serialization of python object
by Robert Ramey 16 Apr '04

16 Apr '04

Ralf W. Grosse-Kunstleve wrote: > Going off on a tangent: does the boost serialization library have support > for portable serialization of large arrays (e.g. std::vector<double>)? Yes - all STL templates are included. Robert Ramey

2 1

intrusive_ptr doc bug?
by Andreas Huber 16 Apr '04

16 Apr '04

Hi there >From intrusive_ptr.html: <quote> Every new intrusive_ptr instance increments the reference count by using an unqualified call to the function intrusive_ptr_add_ref, passing it the pointer as an argument. Similarly, when an intrusive_ptr is destroyed, it calls intrusive_ptr_release; this function is responsible for destroying the object when its reference count drops to zero. The user is expected to provide suitable definitions of these two functions. On compilers that support argument-dependent lookup, intrusive_ptr_add_ref and intrusive_ptr_release should be defined in the namespace that corresponds to their parameter; otherwise, the definitions need to go in namespace boost. </quote> It's the last 8 words that don't make much sense to me. That would force some libraries using intrusive_ptr to make using declarations or directives in headers. IMHO there's no other choice but to put the two functions in the global namespace for compilers that do not support ADL. What am I missing? Thanks & Regards, Andreas

2 2

Re: Re: Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

"Peter Dimov" > The types in l_ are always add_value processed, the types in the other listN > that stores references to the arguments at the call site are not. In > > bind(f, a1, a2)(b1, b2); > > bind(f, a1, a2) creates a list2 that holds the values of a1 and a2, > add_value-processed. The call (b1, b2) creates a list2<B1&, B2&> that holds > references to b1 and b2. > > These are all implementation details. I don't see why you seem so worried > about them. In particular, add_value is only present because of the need to > support MSVC 6. On a compiler that supports partial specialization, it's > possible to use an unadorned list2<A1, A2> as l_. Many other implementation > variations are also possible. Okay, now that I know add_value is a workaround, that clears up a bit of my confusion. I'm working on a typelist variety of bind that works with Loki typelist defined functors. My apologies for my wording of my initial confusion with the bind library. I should have thought about asking why bind was designed thus in a less arrogant way than I initially asked. Hopefully bad first impressions on boost are forgotten faster than bad first impressions with parents. Best, John

1 0

Re:[boost] Re: [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > Thanks for the link. However, the current BOOST_CLASS_EXPORT mechanism > will not work with DLLs. That's because global/static variable (the > extended_type_info_typeid instance) is not shared by DLLs. > I guess we may have to make the serialization library a dll and export > the extended_type_info_typeid instance as a global variable. Clearly you understand the main issue here. I believe its fixable although I'm not sure that making the library a DLL in itself will addresse it. Basically we have to find the tweak so that there is one and only one type table be it in the main program or in the DLL of the library. I'm sure it will require a subtle adjustment in the library. If you managed to figure this out let me know. I'll also take a look at it. Robert Ramey

1 0

Re: [boost] [serialization] register_type and dll/so module
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > In the serialization library, when classes are never serialized directly > but rather through a pointer to the base class, the user need to call > register_type so that the archive contains information about the derived > classes. > However, sometimes those derived classes are implemented in another > dynamic loaded (dll/so) module. The type of the derived classes will > not be known at compile time. How can cope with this? Does the library > provide any facilities to help the user in this situation? This is still under consideration. Right now its not clear what the best way to handle this is. The package contains demo_pimpl and I have a demo_plugin example on my desk - but I don't think I'm ready to give a good answer to this question. Just going into speculation mode I would consider: a) build the library as a DLL. b) build the serialization of another type as another DLL c) use BOOST_CLASS_EXPORT for the ser d) pray that the type registration maintains a single type/key table in the main program or library DLL data space. So clearly we're into new territory here. Your questions suggest that you're taking the serialization library to places were no one has gone before. Just out of curiosity, what is the application you're working on? Robert Ramey

1 0

[serialization] + [boost.python] serialization of python object
by Robert Ramey 16 Apr '04

16 Apr '04

Li Lirong wrote: > According to the documentation of boost.python, > one can derive from c++ base class in Python and override the virtual > functions in Python. However, is it possible to serialize the objects > of the python class using the serialization library? I think we're a little ways off from that. If you want to get started now take a look Plugin Archive Adaptor in the manual section "Future Directions" Robert Ramey

4 3

Re: Re: Re: reference binding
by Dill, John 16 Apr '04

16 Apr '04

> So e.g. list1 is always instantiated with a reference type, to what? the original type, or the add_value processed type? > and thus it > also stores the arguments > as references. I still think that those types are processed by add_value before being used. The bind_t L template parameter is instantiated with a list of add_value modified types through list_av_N in the bind calls, which leads me to believe that the listN represented by l_ object in bind_t has types of either value<T>, reference_wrapper<T>, or other bind_t structures. So are the types stored in listN (A1, A2, ... ) ever the original type or the original reference type? Or are they always add_value<T> processed? Many thanks 4 your time, John

2 1

gcc34 , boost::random problem
by Neal D. Becker 16 Apr '04

16 Apr '04

In file included from /usr/include/boost/random.hpp:46, from TestPn.cc:1: /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::init_modulus()': /usr/include/boost/random/lagged_fibonacci.hpp:276: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In member function `void boost::random::lagged_fibonacci_01<RealType, w, p, q>::seed(It&, It)': /usr/include/boost/random/lagged_fibonacci.hpp:309: error: `std::fmod' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp:310: error: `std::pow' has not been declared /usr/include/boost/random/lagged_fibonacci.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::lagged_fibonacci_01<RealType, w, p, q>&)': /usr/include/boost/random/lagged_fibonacci.hpp:357: error: `std::pow' has not been declared In file included from /usr/include/boost/random/ranlux.hpp:25, from /usr/include/boost/random.hpp:47, from TestPn.cc:1: /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::init_modulus()': /usr/include/boost/random/subtract_with_carry.hpp:268: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(uint32_t)': /usr/include/boost/random/subtract_with_carry.hpp:280: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In member function `void boost::random::subtract_with_carry_01<RealType, w, s, r, val>::seed(It&, It)': /usr/include/boost/random/subtract_with_carry.hpp:295: error: `std::fmod' has not been declared /usr/include/boost/random/subtract_with_carry.hpp:296: error: `std::pow' has not been declared /usr/include/boost/random/subtract_with_carry.hpp: In function `std::basic_ostream<_CharT2, _Traits2>& boost::random::operator<<(std::basic_ostream<_CharT2, _Traits2>&, const boost::random::subtract_with_carry_01<RealType, w, s, r, val>&)': /usr/include/boost/random/subtract_with_carry.hpp:351: error: `std::pow' has not been declared

1 0