[boost] Re: Re: Re:Re: Serialization Formal Review #2

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-04-28 17:40:44

Peter Dimov wrote:
> From: "Fredrik Blomqvist"
>> Peter Dimov wrote:
[snip]
>>> the general idea is that they keep a
>>> map< shared_ptr<void>, int > on writing, mapping every shared_ptr
>>> ownership group to a pointer id, and a corresponding map< int,
>>> shared_ptr<void> > on
>>> reading, for the reverse transformation.
>>>
>>> The main problem for implementing a non-intrusive serialize() for
>>> shared_ptr is that these pointer maps need to be held in the
>>> archive, which requires either archive modification, or a general
>>> "extra
>>> state" support in all archives.
>>>
>> Hmm, in my implementation I _don't_ save anything but the raw-ptrs to
>> the archive. Only at load-time is a temporary map maintained that
>> intercepts loading of smart_ptrs and "seeds" them starting from the
>> first one.
>
> It's pretty much the same either way (assuming polymorphic classes and
> dynamic_cast<void*>(p)). The only case that comes to mind where the
> two approaches differ is when you save a shared_ptr<T>, then a
> shared_ptr<void> that shares ownership with it but points to a
> subobject. But this isn't a very important case in practice.
>
> I used a shared_ptr-specific map because I haven't even tried to
> handle raw pointers (by design) since a raw pointer can have so many
> meanings that - I decided - there was no reasonable default.
>
Perhaps I'm being slow here, but I still don't understand why you need to
save the extra map-information to the archive? What do you gain?
Regardless of the raw-ptr issue, couldn't you simply treat any pointer
in the archive as a shared_ptr then?

// Fredrik