Re: [boost] [serialization] Regressions?

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-06-24 20:13:57

On Fri, 24 Jun 2005 09:19:05 -0400, David Abrahams wrote
> "Robert Ramey" <ramey_at_[hidden]> writes:
> 
> > David Abrahams wrote:
> >> Vladimir Prus <ghost_at_[hidden]> writes:
> >> 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. 
> 
> Au contraire; it does.  It's easy enough to set up a little graph of
> objects on the stack.  I'd like to be able to load that back in and
> ("obviously") get dynamically allocated objects.  Why is that
> nonsense?
> 
> I know a computational physicist who wants to serialize very large
> matrices, which are invariably going to be objects on the stack.  Why
> is that nonsense?

It's a valid use case -- the need for stack-based serializaton happens all the
time with value-based objects.  There are all sorts of places in a program
where objects are constructed on the stack, initialized, changed, and then
perhaps serialized. I might even serialize the same object more than once with
modified contents. They can't be const because they are changed or assigned
after construction.  

I really don't want a different syntax to remember.  operator<< invokes a good
analogy in my brain to remember -- '&' doesn't.

> > 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 ?
> 
> You mean
> 
>   ar & my_non_const_object
> 
> works?  If so, I'm less worried.  However, the non-uniformity seems a
> bit gratuitous, and I think you're setting a bad precedent by 
> equating non-const with "will change," even if that interpretation 
> is overridable.

I'm worried people will get in the 'habit' of casting to use serialization.
And in the real world that won't be using fancy C++ casts -- they'll get out
the big bad c-cast hammer.  And IME once the casting starts it has a way of
growing -- programmers see the casts and 'learn from them'.

> >> I'm starting to care.
> >
> > The whole thing has been blown waaay out of proportion.
> 
> Maybe.  These days, I am putting a lot more attention on small 
> details of libraries that I hadn't seen much of before.  It isn't 
> personal; I am just trying to keep the overall quality high.

I never stopped caring, I just got tired. Since the moment this change went
into the library and blew up date-time tests and some of my other programs
that were working perfectly I was unhappy.  But neither Vladimir or myself
have been able to convince Robert that this change is ill advised -- so I just
stopped and modified my stuff.  I ended up adding something to the date-time
docs so that we can demonstrate stack-based serialization:

 NOTE: due to a change in the serialization library interface, it is now 
 required that all streamable objects be const prior to writing to the 
 archive. The following template function will allow for this (and is 
 used in the date_time tests). At this time no special steps are 
 necessary to read from an archive.

      template<class archive_type, class temporal_type>
      void save_to(archive_type& ar, const temporal_type& tt)
      {
        ar << tt;
      }
    
Feels/looks like an ugly workaround to me...
 
mr-blow-it-all-out-of-proportion-yours ;-)

Jeff