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