Re: [boost] Questions on Serialization

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