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