Re:[boost] Serialization lib comments and problems

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-01-08 17:18:30

Tom Wenisch wrote:

>1) xml archives won't build.
These require new iterators which are not available in 1.30.

2) link problem with void_caster::self_register()

OK - thanks

>3) Registration of polymorphic types

>a) Clearer documentation

In large part to the effors of Pavel Vozenilek the docments are
much improved for the next version.  I'll double check to see that this
point is better explained.

>The "Pointers to Objects of Derived Classes" section of the docs talks
>about loading an object through a base pointer, and why registration is 
>neccessary. 

>From reading this, I did not understand that registration
>is also neccessary when writing to an archive.  

durring save - a table is built which assigns sequencial integers
to classes. durring load, the table is rebuilt.  So the same
sequence of classes has to be processed so that the tables
match.

>Also, when using
>register_type<>, it isn't clear in the docs if the types need to be
>registered in the same order to deserialize, but I presume this is the
>case.  Is this true? 

yes

>Can I avoid this requirement with the EXPORT mechanism?

yes - The motivation for including the EXPORT mechanism is to 
permit one to avoid explicit forward registration.  This relates
a string key to the class.  The only requirement is the
the writeing and reading programs use the same mapping
from key to class.
 
>b) export.hpp broken under gcc 3.3.2

>I got all sorts of nasty compile errors when I tried to include
>export.hpp.  I did not investigate them, since I was able to get things
>working with the register_type<> mechanism.

You're going to want/need  this.  run the test_exported.cpp test and
let me know of the results.  send the beginning part of the
compiler error listing.

>c) registration and templates

> I have a bunch of templates which produce types which I want to
>  serialize.  I have written serialize code for them, and they work
>  swimmingly.  The problem is with registering them with register_type<>.

remember that the issue of regstration only applies to derived pointers of 
polymorphic base classes not all types.

>  What I would want is to automatically register templates when they are
>  instantiated, for example, by having a static member variable in
>  the class whose constructor does the registering.  But there are a
>  number of problems with this idea:  You have to register with a specific
>  archive object, which doesn't exist in my use case until I actually go
>  to save.  

check the example demo.cpp. In this case the serialize function
of bus_route registers all the types of bus_stops.  So registration
is automatically done when and only when necessary.  However
it does mean that a new type of bus_stop implies updating
of bus_route serialization.  This is the example that motivated
export.

>  Also, how do I enforce that the same set of templates are
>  instantiated, in the same order, in the program which
>  deserializes?  Clearly, if the instantiation doesn't exist, you won't be
>  able to load the object. 

I believe that getting export to work will help you.  templates can't be
passed to the EXPORT macros however. You'll have to study
export.hpp to make it work for templates.

> In my use case, it would be extremely helpful
>  if the library were able to generate an error message that indicated the
>  name of the type (using typeinfo) that is missing, so I can go and add
>  an explicit instantiation to the loading program.  Any thoughts or
>  advice on these issues?

This is the fundamental conundrum that make the whole registration
system necessary for derived classes from a polymorphic base.
The base serialization code can be compiled independently of
the derived code.  Lack of registration will generate a run time error
its the best I was able to do.  EXPORT may work best for you.
     
>4) BOOST_IS_ABSTRACT() and incomplete types

>  Can I place the BOOST_IS_ABSTRACT macro at a location where the type it
>  is naming is incomplete? 

I believe so;
 
>Same question for the EXPORT macros.

no - it should go in the header for the serialization code for the class.

>5) serialize::access does not work with template types. (gcc bug?)

>This one is almost certainly a gcc bug.  serialize::access grants the
>serialization code access to private constructors of the class to be
>serialized, and this works correctly for non-template types.  However,
>in templates, gcc claims that the constructors are not accessible within
>serialize::access, despite the friend declaration.  Anyone seen this
>behavior before?

I don't know that I've tried this - I would like to see a small example.
I've built with gcc 3.2 and msvc 7.0

>That's all I have for now, though I am sure there will be more.

>I look forward to seeing this library included into Boost soon!!!
a) it has to get on the review schedule
b) boost 1.31 has to be released
c) then it has to get reviewed.

You usage in a "real" environment is very helpful.  Thanks

Robert Ramey