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

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.

Robert Ramey