Daryle Walker wrote:
I just looked over this library (since Robert Ramey mentioned part of it as a solution to a different problem). I'm wondering how (future) Boost library code should implement serialization. Right now, the Serialization library contains code to serialize "shared_ptr" types. Should the Serialization library contain similar code for every potential Boost type, so should each type include the code?
Right now the code is in the library that is maintained by the persone who wrote. After doing the whole STL, I'm trying to stay away from the serialization code writing business. I've made some exceptions such as shared_ptr for reasons that aren't interesting here. In general the long term approach has to be that authors of individual libraries add serialization to their own libraries. This has worked out well for date-time, multi-index and perhaps others.
If the latter is the answer, then does:
class my_type { friend class ::boost::serialization::access; //... };
need a forward (or full) declaration for "access" before it? Or does that only apply to template functions (or is it just template operators)[1]?
If I understand this correctly, the friend declaration could be restricted to a couple of functions. But compilers are all over the place as to they way they handle this and the above is easy to remember and seems to work well. Of course, you're free to use a more elaborate one for your own classes.
Also, the Contents entries from "void_cast" to "BOOST_STATIC_WARNING" need to be raised a level so they don't look like child entries for "extended_type_info".
It the current version of the manual I see: Miscelenaeous extended_type_info Motivation Runtime Interface Requirements Models void_cast utf8_code_cvt BOOST_STRONG_TYPE state_saver Datafow Iterators smart_cast BOOST_STATIC_WARNING Rationale That is, void_cast is not show as part of extended_type_info. And I think some of the demo programs could
use a sprinkling of "std::auto_ptr".
LOL - and perhaps a little bit more. When the test system introduced automatic memory leak detection, I noticed for the first time that lots of the demos and tests had memory leaks. It doesn't affect the validity of the demos and tests but it does look a little sloppy. I'm reluctant to fix this as I'm concerned about complicating the demos and diminishing their tutorial value and about complicating the tests. Maybe someday. Robert Ramey