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