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
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
- one value save, then N pointer saves sharing the same address should be
- 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. :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk