: [boost] [serialization] Big gotcha with BOOST_CLASS_EXPORT

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-01-21 13:26:47

Robert Ramey wrote:

>>Is it possible to always save proper identification when saving a pointer to 
>>polymorphic objects?

>This looks like an error to me.  The intention is that it work as you expected.
>I'll look into it.

well, I've looked into it.

basically the problem comes down to  the following situation

class B {}
class D : public B {}
...

D *d
ar << d;
...
B *b
ar >> b;

That is, the sequence of classes saved is different that the sequence of
classes loaded.  This issue is not related to just pointers but all object
whether serialized through pointers or directly as objects.

The central organiising principle behind the implementation of the
serialization library is that classes are "seen" in the same sequence
on saving and loading - thereby permiting the invocation of the appropriate
serialization code.

In most cases an attempt to violate this principle is an unrecoverable
error commited during compile time that isn't noticed until run time.

In the special case of exported pointers, it is possible that such
an error could be "fixed up" at runtime. The problem with this would be:

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.

b) it would "fix up" some mistakes but not detect others of a similar
nature - e.g. when the save objects don't match loaded objects and
the objects are not serialized though pointers.

c) it "fixes up" what I would presonally view as a programmer oversight
which might well come back to haunt the programmer in an even
more subtle form.

So I'm not in favor ot the idea of always saving identification for
exported pointers.

I've considered in the past the idea of a "debug option" for archives.
The most common error in a complex serialization scenario - e.g.
is when save/load get out of sync.  This can easliy happen when
a class definition is changed and an error is made in handling
previous class versions.  This can be torture to find - as you
know from first hand experience.   This would add extra information
to the archive - basically begin/end class flags that would
be checked on load.  

I have left this a future idea because - well you can imagine.

Also, the introduction of the "&" serialization operator goes
a long way to avoiding the whole problem in the first place
so it occurs much less frequently than before.

Robert Ramey