Vladimir Prus <ghost@cs.msu.su> writes:
On Thursday 12 May 2005 20:19, Robert Ramey wrote:
I'm not sure this behaviour is right. It certainly matters if I save the *same* object as pointer or not. Why does it matter if I have *another* object by pointer.
Suppose you've saving an object with the same address twice. There possible situations are:
1. Both saves are via pointers. You enable tracking for this address; only one object is actually saved. User is responsible for making sure that the object does not change between saves.
2. First save is via pointer, the second is not by pointer. You throw pointer_conflict.
3. First save is not by pointer, second is by pointer. You ehable tracking for this address.
4. Both saves are not via pointer. You don't track anything.
Is there anything wrong with above behaviour?
That looks perfect to me.
Exactly. As I've said above, I believe saves of 'x' inside the loop should not do tracking since we're not saving via a pointer.
How do we know that one of the x's saved in the loop is not serialized as a pointer somewhere else?
You keep a set of addresses of all saved objects.
I know I'm coming in late here, but I have always expected that the library worked this way (actually keeping a map of saved object address to archive identifier is a usual arrangement). If it doesn't do that, I'm very surprised. How else do you do tracking? Also, if tracking a stack object is being made illegal unless it's const, I find that highly surprising, and I see no relationship between its constness and safety due to lifetime issues in this case. I could easily build a small self-referential structure on the stack that I'd like to send to a archive, and non-constness would be essential in such a scenario. Of course I could create const references to each object and serialize those but why make me jump through hoops?
I don't understand anything of the above. To give another example:
const X x; const X& x2 = x;
are you saying that saving them works differently?
I don't think that's possible; the expressions 'x' and 'x2' are identical in all contexts.
But I've checked and nothing's wrong. So I either have to modify my design -- which I don't want, or add very strange-looking cast.
You have three other options: a) use & operator instead of << b) set the tracking trait to "track_never" c) tweak your code so the trap is never invoked. (hypothetical only)
By the way the const_cast is a good choice for another reason.
const_cast is almost never a good choice for _adding_ constness. Use implicit_cast.
I'm curious if anyone else is following this thread. Its getting pretty deep in the details of the serializaiton library.
Yea, looks like nobody cares much.
I'm starting to care. -- Dave Abrahams Boost Consulting www.boost-consulting.com