Re: [boost] [serialization] Regressions?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-06-25 16:35:24

Robert Ramey wrote:
> Peter Dimov wrote:
>> Robert Ramey wrote:
>>
>> 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.

For several reasons, the most important one being that tracking is on by 
default.

But more fundamentally, address tracking is not a property of the type. It 
is quite possible that the same type X is used in one serialization session 
as non-trackable and in another as trackable. The author of X doesn't know 
how the type will be used, so he can't mark it as track_never. It becomes 
the responsibility of the person who actually serializes X to mark it 
appropriately (and it's not possible to supply different tracking levels for 
two parts of the same program AFAICS.)

Most of these users of both the serialization library and X are very likely 
to not mess with the default tracking level; even if they do, they might 
forget about a type or two; and sometimes they'll never see the X being 
serialized because it might only be part of another object Y.

I think that the default behavior on a sequence of two saves with the same 
address should be to write the two objects, as if address tracking isn't on. 
If later a pointer to that address is saved, an exception should occur. Or 
more generally,

- one value save, then N pointer saves sharing the same address should be 
OK;

- M pointer saves sharing the same address should be OK; (*)

- K value saves sharing the same address should be OK and result in K copies 
in the archive;

- all other sequences raise an exception at first opportunity.

Is there any reasonable use case which is prohibited by the above rules?

(*) This promotes questionable coding practices but is consistent with the 
current behavior. :-)