$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Serialization] Bizarre bug
From: Jarl Lindrud (jarl.lindrud_at_[hidden])
Date: 2009-08-09 05:57:27
Robert Ramey <ramey <at> rrsd.com> writes:
> >
> > But getting back to the original problem - really the most important
> > thing here is that the default tracking level should be unaffected by
> > compile-time instantiation. As long as I know what the default is,
> > and that it won't change under my feet, then I would be OK with that.
> >
> > Would that be feasible to implement?
>
> Just specify your own setting with BOOST_CLASS_TRACKING(mytype,
> track_always)
> or BOOST_CLASS_TRACKING(mytype, track_never) for your own
> classes.
>
> If this is too much - then you could tweak the "tracking.hpp" file
> so that the default is "track_always" or "track_never" or whatever.
>
OK, I think we can wrap this up then... My understanding now is :
-----------------------------------------
* If one program writes archives like this:
ar & vec; // vec is a std::vector<char>
, it is then impossible to reliably load that archive in another program,
unless one is aware of the entire compile-time content of the first program.
* When one writes code like this:
ar << pVec; // pVec is a vector<char> *
, it has the compile-time side effect of silently changing the archive format
for *all* archives produced by that program, that happen to include a
vector<char>. Making matters worse, the archive format change is compatibility-
breaking.
-----------------------------------------
IMHO, this is a rather fragile state of affairs, but it's your call and I won't
argue it further. I'll go with the workaround, and document to users of my
library, that if they use B.Ser. to serialize vector<char> (and presumably a
number of other types?), they must always write
BOOST_CLASS_TRACKING(vector<char>, track_never)
, and that failure to do so is likely to trigger silent deserialization errors
in other programs.
Regards,
Jarl.