Re: [Boost-users] Serialization and reading from a const object (was: [Serialization] Serializing a map)

From: Robert Ramey (ramey_at_[hidden])
Date: 2006-05-24 18:04:27

Thorsten Ottosen wrote:
> This issues seems to pop up again and again.

It's true that from time to time this question comes up. Though
not very often it seems to me.  On the other hand, since I've
put this in I havn't had anyone complain that they've invalid
archives (well maybe a couple of times due to bugs in
in serialization code - but that's different.) which was a big
pain in the rear to try to explain before.

>It's just *so*
> surprising (nobody reads through all the docs of a library when they
> start to use it).

> As you remember, I had to contact you personally to help me with
> Pointer Container Serialization --- it was not because I hadn't tried
> before contacting you (I spent hours trying to figure out what was
> wrong). (I have documented a seperate todo-list for people using
> Boost.Pointer Container and serialization just to remember them of
> this isssue!).

> There has to be a better way. I read through your scenario again:
>
>    http://www.boost.org/libs/serialization/doc/rationale.html#trap
>
> and I don't get very much of it.

> I understand the need for ensuring
>
> 1. no invalid archives are created.
> 2. no data is lost.
> 3. no runtime errors occur.

> but there has to be a better way, even if it means
> 3 becomes a runtime exception.

Hmmm - to ensure 2) that would have to occur
on archive save - I'm not even sure that's possible.
Even so it lot harder to track down than the current setup.

> Somehow the information of a class and how it is serialized must be
> localized ***in one place only*** so one programmer can't ruin the
> archieve of another programmer without his knowlegde.

In my view all that should be in the header module which declares the
class.  This is always possible and that's what I always do. It's
always grouped together in one place in one module.  Personally
I don't understand why everyone doesn't do it that way.  Maybe
we need a macro which specifes all the serialization traits for a type
like BOOST_CLASS_TRAITS(tracking, abstract, etc...) rather
than just letting people sprinkle them will-nilly all over their code.

> If this means
>
> 1. that by default, you can't serialize a pointer (you must ask for it),
> 2. that by default, you have to define BOOST_SERIALIZATION_TRACKING

> BTW: I'm ok with
>
> T * t;
> ar >> t;
>
> failing (just make it part of the toturial). That's completely

> different from reading from an object.

Hmm - I'm doubtful that would be a popular idea.

But, you want to establish a different default policy for your own company, 
you could
easily tweak tracking.hpp so that the default would be track_never,  - but 
then
you'll get a trap when you try to serialize a pointer - which I guess would
be what you want.

We've had some experience with this and from my standpoint its been 
positive.
This was discussed at length and I've conceded that knowledgable
people can disagree on this point.   So I do have a couple of ideas
which mollify those who disagree on this point.

a) I could change the BOOST_STATIC_ASSERT to BOOST_STATIC_WARNING
This would emit an warning message on most compilers.  Then people are
free to ignore it.  Of course from one standpoint its worse, some people 
will complain
about the warning then ignore it and then complain again about creating an 
unreadable
archive - LOL.  So I'll have the worst of both worlds.

b) We could make the emmision of the message (assert or warning) conditional
or suppressable via definition of something like BOOST_SUPPRESS_WARNINGS
(which could be part of BOOST_STATIC_WARNING).

The argument that people don't/won't read the documentation doesn't evoke
much sympathy from me.  On one hand we want to permit someone to make
an egregious error so that he won't have to read the manual to understand
the nature of his error. I don't buy it.  In the code where the static 
assertion
occurs there is a pointer to the explanation in the manual.  It bother's me
much less to have someone complain about this error than it does getting
email titled "bug in serialization" from people "too busy" to read the 
portion
of the manul pointed to by the comment in the line where the error message
is emitted.

I want everyone to be successful using the library - even if they complain
that it requires them to write good code.

Robert Ramey