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

From: Fredrik Blomqvist (fredrik_blomqvist_at_[hidden])
Date: 2004-04-26 10:16:17

Peter Dimov wrote:
[snip]
>
> FWIW, in my own library I do, indeed, have a special case code for
> serializing an unmodified shared_ptr, for two reasons. First, this
> shows
> that the library is flexible enough. Second, even if we modify
> boost::shared_ptr to be boost::serialization-friendly, we won't be
> able to patch std::tr1::shared_ptr.
>
Interesting to hear that this approach has been used by more people!
I also believe being able to handle almost any smart-ptr would be a
big plus. Some monolitic frameworks "force" you to used their smart-ptrs
for example...
Do you use some kind of general registration mechanism for the classes
that needs this treatment btw?

[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.
Is the're something I'm missing with this approach? I guess such an
implementation would be more complicated without a baseclass(?) (as in
the CommonC++/MFC case). Otherwise I can only see how it allows less
"strict" enforcement of load/save symmetry. I.e it would enable
smart-ptr<->raw_ptr transfer. Bug or feature? ;-)

Regards
// Fredrik Blomqvist