Re: [boost] Re: [serialization] Regressions?

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-05-11 01:19:17

On Tue, 10 May 2005 11:36:27 +0400, Vladimir Prus wrote
> Robert Ramey wrote:
> 
> >>> instantiated from this code of mine:
> >>>
> >>>         ofstream ofs(av[2]);
> >>>         boost::archive::binary_oarchive oa(ofs);
> >>>         oa << *data_builder.finish();
> >>>
> > 
> > This code should be considered erroneous.  The documentation in 1.32
> > addressed this but unfortunately the enforcement was lost in the shuffle.
> 
> Excuse me, but I refuse to accept that this code is erroneous. As 
> I've said, this is my existing design -- the 'finish' function 
> returns non-const pointer. The fact that somewhere else, I serialize 
> the result of 'finish' has nothing to do with 'finish' return type,
>  and I should not be forced to change my existing interface just 
> because I use serialization somewhere.
> 
> > The intention is to trap the saving of tracked non-const objects. This is
> > to prevent users from doing something like
> > For(...
> >     A a;
> >     ...
> >     ar << a; // will save the address of a - which is on the stack
> > 
> > If a is tracked here, instances of a after the first will be stored only
> > as reference ids. When the data is restored, all the as will be the same.
> > Not what the programmer intended - and a bear to find.
> > This is really the save counterpart to the load situation which required
> > the implementation of reset_object_address.
> 
> So, you're saing that "const" == "no allocated on stack"? I don't 
> see why this statement is true. I can just as well do this:
> 
>   void foo(const A& a)
>   {
>          ar << a;
>   }
> 
> and circumvent your protection. Further, how often is it that non-pointer
> object is tracked? I think it's rare case, while saving a pointer is 
> a common case, and making common case inconvenient for the sake of 
> non-common case does not seem right.
>
>... more stuff...

FWIW, I agree that this new change in serialization is wrong.  Even though the
docs warned that this was the design in the last release, it was easy to
overlook since it was not enforced and even the example code did not live to
the 'everything to be serialized must be const' rule.  So basically this is
going to break alot of existing code and I think for dubious benefit....

Jeff