Re: [boost] [serialization] Regressions?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-23 23:30:41

David Abrahams wrote:
> Vladimir Prus <ghost_at_[hidden]> writes:
>

> I know I'm coming in late here,

Yes you are.  the original post was sometime ago and many of the issue on
this subject were discussed.

> but I have always expected that the
> library worked this way (actually keeping a map of saved object
> address to archive identifier is a usual arrangement).  If it doesn't
> do that, I'm very surprised.  How else do you do tracking?

Of course it works that way.  It turns out the the library is sufficiently
smart to skip tracking (and skip instantiating the code for tracking the
indicated type)  for types which are never serialized through pointers.  The
mechanism for implementing this is somewhat unusual and it seems may have
caused a mis-apprehension as to what is going on here.

> Also, if tracking a stack object is being made illegal unless it's
> const, I find that highly surprising, and I see no relationship
> between its constness and safety due to lifetime issues in this case.

Tracking a stack object makes no sense. doing so will result in an archive
that cannot be loaded.

Tracking an object whose value can change during the lifetime of an archive
will also fail when the archive is loaded.

by requiring the << operator to take a const argument when the object is of
a type that is being tracked, violations of the above rules can often be
detected at compile time - thereby saving the programmer days of work
looking for a mistake that will only be detected after a failed attempt to
load a corrupted archive. (BTW, I'm the one that get's the email when this
occurs)

Its concievable that there mght be a legitimate case where one wants to
track an object that is not const during the course of serialization - but
no one has presented a credible use case so far.  There are cases where the
STATIC_ASSERT trips when its not stricly necessary but in all of my cases I
found it easy to slightly restructure the code to avoid the problem.  See
Joaquin's previous post on this subject.

In he rare case where one needs to do ar << t where t is not a const and it
is inconvenient to alter the code to make it so, one has two options:  Use a
const_cast or use the & operator instead of the << operator.  Is this such a
price to pay to get traps in usage of the library that is very likely an
error?  Is fair that the rest of have to forego this facility just so one
programmer doesn't have to write ar & t instead of ar << t ?

> I could easily build a small self-referential structure on the stack
> that I'd like to send to a archive, and non-constness would be
> essential in such a scenario.  Of course I could create const
> references to each object and serialize those but why make me jump
> through hoops?

That's not the case here.  you might build it on the stack but it would have
a type.  Normally that type would be serialized by something like
save(Archve &ar, const T & t).  From then on T is a const and there is no
problem and no trap.  The problem comes when you do somethign like

for(...
    X x = ....()
    ar << x

where X is type that maybe tracked.  I'm sure you can see the problem here
if you're trying to track either to recover pointers or eliminate
duplication.

> I'm starting to care.

The whole thing has been blown waaay out of proportion.

One little observation.  It has come to my attention that const is avoided
by some programmers due to its tendency to ripple its effect throughout the
code.   Personally I think this is a great mistake and the extrat pain in
the neck caused by this ripple effect is more than compensated by the
detection of bugs resulting from side effects.  This feature reflects my
views on this subject.

Robert Ramey