Re: [boost] [serialization] Regressions?

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-06-25 11:21:47

On Fri, 24 Jun 2005 23:11:31 -0700, Robert Ramey wrote
> Hmm I'll take a look.
> 
> >>  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.
> 
> I'm not sure what the above means.

The object has to be const in the current context to stream it.
 
> What is true is that the state of an object should not be changed durring
> the process of serialization.  That is the statement made by save(Archive
> &ar, const T & t).

It's more than that.  You can always pass a non-const to a const method and
expect it to return unchanged.  You can't currently serialize an object in a
non-const context -- hence the workaround.

> > Actually that's not even accurate.  Forming a const reference to an
> > object doesn't make the object const.  The fact that this design makes
> > you write something hard to explain might be a clue that it isn't
> > helping.
> 
> The problem you had was the same as mine when writing the tests.  The
> typical code was
> 
> A a, a1;
> 
> text_archive oa(..)
> oa << a;
> ...
> text_iarchive ia(..)
> oa >> a1
> 
> BOOST_CHECK(a == a1)
> 
> Of course this was easy to fix (just make use const A a1) but other cases
> required a little more work - but never very much.

Again -- we're arguing over a trivial testcase where you might be able to
easily create a const object.  Just because this little testcase can easily
make A const doesn't equate to whether I want to do that in a 'real program'.
 I've written lots of programs that build up and objects on the stack and then
write them out to a file.  Now I'm forced to put a function wrapper around
things to use serialization.  Sorry if this isn't a 'real enough' a use case
for you, but I thought that was one of Vladimir's points as well.
 
> But I argue - as Joaquin did.  That  the above situation is not at 
> all typical and that in typically the situation almost never comes 
> up.  Of course that is speculative on my part.  But so far I've only 
> gotten objections from library testers.  

The way you wrote this it appears that you value testers opinion less -- I
think you should reconsider because a bunch of the library testers are also
boost 'power users'.

> Vladimir came up with a 
> bunch of cases but they seemed very atypical to me.  The were at 
> best usages of the library in ways that have never occurred to me so 
> it was hard for me to be convinced.

I think his cases are valid and I said so.  

> That's why I say I believe its been blown waaaay out of proportion.

That's your view and you're sticking to it. I had accepted it and moved on
figuring that at some point after the 1.33 release the wave of user complaints
would finally force you to reconsider.  

> Yeah - just like the whole "const" business in the first place?
> 
> For what its worth there are a couple of incidental aspects of this
> situation that might be interesting.
> 
> a) This whole thing is implemented by one STATIC_ASSERT in oserializer.hpp
> which can be commented out

I'd put that in the FAQ right now and make a compile option to turn it off --
that would alay my concerns and will make it trivial for all of us to answer
the user questions.  You're not the only one that's going to have to deal with
this.

>...snip...
>
> I would like to wait and see how this works for a while.  So far 
> I've heard from
> 
> myself - library writer
> Jeff - wrote serialization test for date/time

You assume alot about things you don't know.  I have other programs that have
nothing to do with date-time that depend on serialization that were broken by
this change.  Perhaps that wasn't clear in my other correspondence.  

> Joaquin - wrote serialization for mult-index - a tricky job
> Vladimir - using in in real code.
> Dave - not used the library in any way
>
> As far as I'm concerned we really have only one data pont (Vladimir) 
> which really addresses what the discussion is about. So lets relax a 
> bit and let some more experience trickle in for a while and see what 
> happens.

I'm sorry you've dismissed the rest of us as heretics :-(  I'm done with this
thread now for good -- you've known my view for a few months and chosen to
dismiss it -- that's your right.  

As for the experience part, only a very small number of people use CVS -- most
use the releases.  This much discussion of a library change prior to it's
release is highly unusual -- I expect more of a flood than a trickle once the
release occurs, people start upgrading, and programs start breaking.  And
that's why I think this IS a big deal...

Jeff