Re: [boost] [serialization] Regressions?

From: Robert Ramey (ramey_at_[hidden])
Date: 2005-06-25 15:34:48

Peter Dimov wrote:
> Robert Ramey wrote:
>
>> ar << f(...); // function returnng a value on the stack to be
>> serialized
>>
>> I'm not saying they are necessarily bad, but I do find them
>> surprising and to me, in explicable.
>
> This is pretty straightforward value-based serialization. It looks
> inexplicable to you because the library uses an identity-based
> approach by default, where the address of the object is important.

No argument there.

>
> There are cases where you only care about the value being saved, not
> its identity. You want '4' in the archive, you don't care which
> specific '4'.

That's why the STATIC_ASSERT doesn't trap if the type is marked as
"track_never".  For such items where you only care about the value the
"track_never" trait should be set for efficiency reasons if nothing else.
The case in my mind was something like pixels in a photograph.

So I would amplify my statement above that I can't understand why someone
would use the above on an type that might track the address.  Sorry that
wasn't more obvious.  Of course it raises the question as to what the
inverse of the operation is.  It can't be ar >> f(..) unless f(..) returns a
refence -but then ... etc.  As I said, when I see something like that I
can't discern the programmers intention and it certainly seems that it might
be something that I didn't provide for when I wrote the library.

> One situation where this happens often is when you have a specific
> file format that you need to support. For example, application A uses
> the serialization library to read/write objects of some type X.
> Application B
> has to be compatible with A's file format, but its internal data
> structures do not resemble X at all. So B does the following: on
> save, construct a temporary X from its state and serialize it; on
> load, deserialize a
> temporary X and construct its state to match. IOW:
>
>     ar << construct_X_from( *this );
>
> and
>
>     X x;
>     ar >> x;
>     construct_from_X( *this, x );
>
> You have repeatedly said that such cases are atypical, but this is
> not so. File formats are important; old data is important.

Well, I think they are atypical.  This particular situation has indeed come
up.  That is there have been attempts to use the library to match a
particular external format but these have not been successful as it
conflicts with another fundamental feature of the serialization system.
That being that the data is driven by the C++ data structures.

I concede that your example above would trap but in fact, type
construct_X_from should in this case be marked as "track_never".  It can
make never make sense to try to track this type in this context and marking
it as "track_never" will be much more efficient to serialize/de-serialize as
well.

This is exactly the thing I'm thinking about.  Without the trap, the user
would have no clue that he is doing something he really doesn't intend to
do.  Of course he might say "I want to track it anyway" or he might say -
well maybe in this example but ...

Robert Ramey