From: Robert Ramey (ramey_at_[hidden])
Date: 2004-04-26 13:02:23
Peter Dimov wrote:
> 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.
The main problem I had was that certain member variable weren't accessible.
The STL collections don't have that issue so there was no problem.
> 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.
That's pretty much the same as what the serialization system does - albeit
in perhaps in a more generic way. Its not clear to me how enhanced library
code could be made to work work without granting access to shared_count. Of
course, if access is granted to shared_count, then everything works already.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk