|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2005-06-23 10:48:12
Vladimir Prus <ghost_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk