Re: [Boost-users] operators << and >> on boost serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-01-08 18:44:30

Thorsten Ottosen wrote:

> Hm. I have a certain feeling that the "trap" is somewhat misplaced.
>
> First of, any solution that is **so** complicated to explain as
> http://www.boost.org/libs/serialization/doc/rationale.html#trap
> tells my intuition that something is not clearly understood yet.
>
> Question: what is the real problem here?
>

> Could it be this: the default tracking behavior is
> "track_selectively". Possibly.

That's it.  This would be the behavior that I would expect most
programmer's desire.  That's why I made it the default.  But
(like other cases where a default is used), it can create
unintended side effects. Hence the trap to make at least
one such side effect visible.

> Your looong example ends with this text: "Eventually, after some code
> restructuring, the differing requirements of serializating
> construct_from are reconciled."
>
> But what do the programmers end up doing? I'm very curious? Is it not
> possible to what the programmers in the example is trying?
> (I'm too stupid here, but I thought it might be possible!)

Basically serializing through a pointer requires tracking to guarentee
that that the de-serialized structure replicates the original.  So
serialization through a  pointer conflicts with tracking turned off.
One programmer has trackng turned off to make a log entry while another 
needs
to serialize a pointer to an instance of the such an entry.  There
are a number of ways to handle this.

a) they could arm wrestle and the loser changes his code.
b) they could define different types - perhaps with a common
base class.  This would allow different attributes in each usage.
c) some other way that hasn't occured to me.

> Anyway, it might be worth considering this procedure:
>
> 1. There is no default tracking level. It must be set explxitly for
> all classes. It should be part of a class' public interface that you
> know it is serializable and that you know *explicitly* what tracking
> it supports.

> Maybe this can be implemented as a macro that must expand
> inside the class, so it can only be provided with the declaration of
> the class.

This would require that one have access to the class definition
inorder to serialize an instance.  Thus one of the main requirements
of the library would have to be set aside.  This is essential to
things like defining serialization.

> AFAICT (*), with that in place, there is not need for "traps".

You're probably correct here.  In this case, the second programmer
changes the tracking behavior and breaks the others code at
compile time.  (similar to what we have now - but more obvious)
Still we would have to explain why this happens - no net gain in
my view.

This is really a question about the usage of defaults and automatic
behavior in general.  The function of such default/automatic behavior is to
make something easier to use correctly.  But taken too far it can
lead to opaque behavior that is hard to understand and modify.
In my opinion BJAM suffers from this.

In this case, I think after all this time that the usage of default settings
as well as the settings themselves are "about right".  Given how
complex the library can/could be to use, its amazing to me that so
few issues come up.

Robert Ramey