Re: [boost] [Serialization] Bizarre bug

Subject: Re: [boost] [Serialization] Bizarre bug
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-08-05 12:47:48

Jarl Lindrud wrote:
> I see this issue has now been closed, without a fix.
>
> In my view it's a pretty serious bug, that this code:
>
>    std::vector<char> v0(25, 'A');
>    std::vector<char> v1;
>
>    std::ostringstream ostr;
>    boost::archive::text_oarchive(ostr) & v0;
>
>    std::istringstream istr(ostr.str());
>    boost::archive::text_iarchive(istr) & v1;
>
>    bool ok = (v0 == v1);
>
> , will fail, because of implicit compile-time instantiation in a
> completely different part of the program.  For the typical user, this
> is next to impossible to diagnose, let alone understand. I guess I
> don't see how this can be thought of as a design feature.

> I would have thought it would be possible to include sufficient
> metadata in the output archive, so that B.Ser. is able to correctly
> deserialize its own output archives, without depending on implicit
> compile-time instantiation.

For collections of primitive types like vector<char> the implementation
level was set to "object_serializable".  The suppresses inclusion of
class information in the archive itself which leads to the the problem
shown by your example.  Perhaps it was a mistake to do this.  But
for every person who would conclude that, there is at least one person
who would conclude that in this case efficiency would be an overriding
concern in this instance.  So its a no-win situation for me.

If you think it's obvious that the wrong decision was made, consider the
following:

a) In order for a situation described in your example to arise in real life
code, a program which saves data would have to include something like
ar << ptr while the program which loads data could not include something
like ar >> ptr.  Were this the case, serialization has been broken in any 
case
so I don't see how the situation in your example could ever arise in real
code.  FWIW, you're the first person ever to report this type problem.

Of course, now I'm a little bit intrigued how you came upon this in the 
first
place.

b) the setting of "object_serializable" is the default.  One make a derived
class override it.

>Sure, that would change the archive
> format, but it would hardly be the first such change, so I would
> think whatever backwards compatibility scheme is already in place,
> could deal with this as well.

If we were convinced that this had to change, it could be dealt with.
Even if I were convinced that the original decision was not the optimal
one, (which I'm not - though I could be),  I would still have to be 
convinced
that the situtuation were so non-optimal that it would be worth the
trouble to address it.

On a regular basis, I get "complaints" that the archive contains "too much"
superfluous information.  Basically, I can't please everyone.  I tried to 
make
reasonable defaults and provide a mechanism for overriding these defaults.
That's the best I can do.

Robert Ramey