David Abrahams wrote:
The member function wasn't my point at all. I just want to be able to save rvalues.
OK - I think I see the problem better. It would seem that you want to serialize a temporay value from the stack. Think about what this would mean in the context of pointers and object tracking. Since tracking is done via object address, and tracking is necessary in order to implement correct restoration of pointers, this can't can't be done reliably.
Have you had a chance to look into this? I've been using a patched version of the library that adds the stated overload and it is working great. Taking out the patch means that where I ought to have been able to simply write
ar << f();
what does f() return? I would expect it return a reference to a constant object of some sort. If it doesn't, then I would expect that its possible that now or sometime in the future, unloadable archives could be created. And the fact that these archives are unloadable would not be discovered until the are in fact actually loaded. Also it would be extremely difficult to determine what the problem is. Finally, it would be very difficult to fixup the archive. Of course the fact that in many particular cases it doesn't create a problem doesn't alleviate my concerns.
I am forced to write code like this:
typename nasty_trait_to_compute_return_type<foo>::type x = f(); ar << x;
If this function is called more than once, then it's possible that the address of the second object serialized will be the same as that of the first call and only an object id will be saved even if the object is in fact different, This is implemented this way to support efficient and correct serialization of pointers and incidently to save storage. In this instance, an archive will be created such that when the second object is loaded, it will be identical to the first object and this will not be correct. This error would be a major problem to find. So I would not recommend your fix above. A better way would be to restrict f() to function which return a const reference to the type returned by the current f(). If that isn't convenient, and one had nothing else to do, he could explore the implications of implementing your proposed specialization so that it traps at compile time if the object might be tracked. This would mean that something like int f() would work while something like my_object f() would likely trap unless my_object was specifically marked as no_tracking. Thinking about this just a tiny bit makes this seem attractive to me. Of course that doesn't mean much until one sets out to actually do it. Robert Ramey
Nasty.
Please?