Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-04-26 05:32:14


From: "Robert Ramey"
> > Regarding shared_ & weak_ptr. If the implementation path Robert outlines
> > in the documentation is to be used I guess an official patch to
> > shared_count is necessary. Would be interesting to hear what the smart
> > pointer experts think.
>
> I agree - the silence is deafining. I know there are applications that
use
> my smart pointer serialization code right now. I implemented and tested
it
> but I don't really know for a fact that it addresses all aspects that need
> to be addressed such as exception safety, threading, and who knows what
> else.
>
> > Otherwise, I still think the solution I outlined in my previous review
> > that doesn't require modifying shared_ptr could be considered. Downside
> > being that it most likely adds a special-cased codepath to the
serializer,
> > but as I said I think it would be worth it.
>
> I would hope that the developer's maintaining shared pointer will address
> this. putting special case code inside the serialization library would be
a
> serious mistake. Between code, tests, and documentation, its approaching
> 30,000 lines.

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.

However, should you decide to use your current scheme, I'll happily insert
whatever friend declarations are necessary in shared_count.

I'm away from my computer right now, so I can't paste my read/write
functions for shared_ptr, but 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk