[boost] Re: : [serialization] Big gotcha with BOOST_CLASS_EXPORT

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-01-26 05:07:36

Robert Ramey wrote:

> Vladimir Prus wrote
> 
>>> a) it would require exported strings to always be included in archives
>>> regardless of whether or not they are strictly necessary. - thus
>>> provoking howls from those for whom maximum speed is a main
>>> consideration.
> 
>>Is it really true?
> 
> I'm pretty sure some boost member or other will howl if anything less
> the maximum efficiency is permitted.   And they might even be right.
> I believe that the serialization libary might be useful for marshalling
> data for remote procedure calls.  In that scenario - the common
> case would be lots of little serializations - rather than one large
> one as is the more common case.  In such a case, efficiency
> considerations would be judged differently.

You mean that each RPC call will create a new archive and serialize the data
to the stream? Well, in that case the overhead will be greater, but still
in case of B,D1,D2,D3 example I've given you'll only save bandwidth when
saving 'B' -- which still don't not look signigicant.

And also, another approach would be to use one archive class all the time. 

>>If 'get_b()' decides to return really 'B' and not some derived class, you
>>don't save identification and proper restoring depends on order of saving.
>>So, if I change loading code to
> 
>>    ia.template register_type<A>();
>>    B* b;
>>    ia >> b;
> 
>>I'll read pointer of class 'A'. See attachment for testcase.
> 
> In addition so save/load operations, explicit registrations
> in save/load archives must also be in sync.  It key to
> how the system works.  So the above would have to
> be formulated with register in both save and load or
> neither save and load.  If this is done, no problems
> occur.
> 
> So. I would consider this an erroneas usage of the library.

Ok, the example is not good. So, it looks like the case I've run into is the
only one where problems occur? Even so, but please consider if the time that
users will spend finding a bug is outweighted by performance increase.

>>I don't expect that saving *object* of type A and loading *object* of type
>>B should ever work, nor that it's diagnosed.
> 
> Someday I would like to see this diagnosed.
> 
> In general, the serialization library relies on save/load being
> closely in sync.  Its a key feature/constraint.   Its incumbent upon
> the programmer to maintain this.  

I think I've argued in past that fixed order of registration is very hard to
maintain, and I think that's what BOOST_CLASS_EXPORT is supposed to solve. 

The problems I see now is that BOOST_CLASS_EXPORT needs better
documentation. I'd like to see some standardeese
"pre-condition/post-condition/effects", or some semi-formal description. 

For example, docs say:

    When an export key string is associated with a class, the string is
    written to the archive the first time an object of that class is
    serialized.

IIRC, I've asked you whether "pointer to an object" should be use there.
Suppose it should. But then, it's not clear whether dynamic or static type
of pointer is meant. If dynamic, then currently archives do not behave as
documented -- they don't save string if static type is equal to dynamic.

- Volodya