Boost logo

Boost :

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-08-23 10:44:15

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

> 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:

        Runtime Interface
    Datafow Iterators

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at