Re: [boost] Serialization Draft Submission # 2

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-03-20 02:06:42

> rameysb wrote:
> > In addition to the original list of requirements (see below), and in
> > reponse to comments from boost members, I have implemented the
> > following enhancements:
> >
> > 1) Archives are derived from a base class with virtual functions.
> > This allows applications to implement custom archive formats.  The
> > library contains support for archives in character text, native
> > binary data, and wide character text.

> Great. However, suppose I want to serialize data as xml. Do I have a way to 
> do it? I'm not sure if "basic_iarchive" is a good name. It links in my mind 
> with basic_string/basic_istream &c. where "basic" means something 
> different.

a) I don't see this as really being related to XML.  I did originally but I have since changed my mind.  Basically XML contains more information than the minimum required here.  XML is interesting to look into but I think trying to mix it in here would make things terribly muddled.

b) I changed the names of things a couple of times.  Finally I settled on the names you find precisely because they mirror the "basic_" used in the standard library.  

std:string              std:istream                 boost::iarchive 
=======             =========                 ===========
basic_string         basic_istream              basic_iarchive
templates on the above for characters
string                  istream                        iarchive
templates on the above for wide characters
wstring               wistream                       wiarchive
templates on the above for binary output 
-----------	       -------------                        barchive

iarchive >> operators are analogus to istream >> operators

All this is intentional to leverage the namespace already embbedded in my aging brain.

> > 2) More checking has been implemented to detect erroneas library usage
> >
> > 3) Archives no longer need to store class names.  This makes them
> > smaller and portable across platforms.

> I'm missing something and can't easily find it from the code. How the 
> association between classes and class-ids in the stored file is maintained? 

well its in the code - though its not obvious .  The key is that all objects are written and read back in EXACTLY the same order.  Hence we now what class to expect so we don't have to read if from the file.  For polymorphic pointers, the procedure is the same though has subtlties that can only be understood by reviewing the code.  The basic trick is that we "register" the derived class pointers in the same order when we load and save so we can identify the class with the object id which is portable.  If one is truely interested you can follow the code while displaying the charater serialize file.

> > 4) Archives have a header to detect cases of erroneas usage.
> >
> > 5) Objects serialized through pointers no longer require a default
> > constructor. Any constructor can be supported.  This implies that
> > const values and references can be saved and restored for objects
> > serialized through pointers.
> >
> > 6) System should function on platorms that fail to properly implement
> > partial ordering for function templates (e.g MSVC 6)
> >
> > 7) library, test and demo build and function properly on MINGW as
> > well as MSVC 7.0
> >
> > 8) More complete documentation.

> There's one more problem that I've spotted. With virtual base classes your 
> code attempts to save a base twice when serializing the most derived class in 
> a dimond hierarchy. I'll send you an example in a private e-mail.

originally I had code included that suppressed saving of the same object twice.  However this failed in cases where the object saved was a temporary one on the stack - which often happens with STL objects.  I know of no way to address this problem in a general way.   Note that saving/loading the same object twice causes not problems though it is inefficient.  If the this inefficiency is an issue, I believe that the save/load functions will have to be made a little fancier to avoid this problem. 

> Another problem is that strings cannot be serialized, at least in some 
> context. Example will be emailed to you.

I will check your example

> Some minor nits:

> 1. Should 
> 	::boost::whatever
> be replaced with just
> 	boost:::whatever
> ?

that's a good question that I don't know the answer to.  I've seen it both ways.  Does anybody know what the answer is?

> 2. Looks like your source uses tabs, which is contracty to Boost requirements.

> 3. Class 'archive_exception' is better be derived from std::exception. 

> 4. reference documentation is shown up incorrectly in my broser and 
> http://validator.w3.org shows a lot of errors.
I'm using the html editor that comes as part a msvc 7.0 which is major pain.  I will try to address this

> 5. reference documentation in some places says
> 	*static_cast<base*>(*this)
> by it should be
> 	*static_cast<base*>(this)
> Moreover, inside "save" method it should be
> 	*static_cast<const base*>(this)

thank you

> - Volodya

I can tell from your comments and your sample code that you have expended some effort to try this system out.  Thank you very much - this is very helpful.

Robert Ramey