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. 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'. 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.