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. :-)