[boost] Re: [boost::serialization] - serialization + shared_ptrs

From: Jarl Lindrud (jlindrud_at_[hidden])
Date: 2005-04-09 08:17:24

Robert Ramey <ramey <at> rrsd.com> writes:

> 
> Jarl Lindrud wrote:
> > Robert Ramey <ramey <at> rrsd.com> writes:
> >
> > Requiring extra registration macros for shared_ptr<T>, beyond the
> > ones needed to serialize T*, to me indicates a deeper flaw with how
> > Boost.Serialization handles shared_ptr's.
> >
> 
> Hmmm - how do you know it doesn't indicate a flaw in TR1::shared_pointer
> that doesn't specify an interface rich enough to support serialization as
> all the other standard library components do?

shared_ptr's, be they in boost or tr1, _do_ specify an interface rich enough to 
serialize through. If you can serialize straight pointers, then you can 
serialize smart pointers, as long as there is a mechanism in the archive to 
store user-defined objects during the duration of the serialization.

In fact, if you have a map (void *, typeinfo *) -> void* in the archive, exposed 
to the serialization engine, you could then for a given pointer associate 
various diffent smart pointer objects, not just shared_ptr.

The serialization code for a reference-counted smart pointer could be hidden 
behind a macro

BOOST_SERIALIZE_REFCOUNTED_SMART_POINTER( smart_ptr )

and then it becomes trivial to define serialization for any smart pointer that 
eg supports operator= and get() (thats what i meant by "reasonable"):

BOOST_SERIALIZE_REFCOUNTED_SMART_POINTER( tr1::shared_ptr )
BOOST_SERIALIZE_REFCOUNTED_SMART_POINTER( boost::shared_ptr )
BOOST_SERIALIZE_REFCOUNTED_SMART_POINTER( my_own_special_smart_ptr )

So its not a question of adding code to Boost.Serialization specifically for 
boost::shared_ptr, its a question of adding code for reference-counted smart 
pointers in general. Once thats done, serialization of just about any smart 
pointer can be implemented external to Boost.Serialization, through the macros. 

In fact, its just a question of adding the map described above to all the 
archives. Then anyone can serialize smart pointers externally to boost.
serialization, by using the map as they please. And you can use the map for any  
other purposes that might arise, its not intrinsically linked to smart pointers.

> 
> > Why can't it happen?
> 
> a) The author of boost shared pointer doesn't want to include serialization
> implementation in his implementation of boost::shared_ptr
> 

And IMO he shouldnt, not inside the class boost::shared_ptr<> anyway.

> b) I don't want to add code to the implementation of serialization to handle
> one particular data type.  This strikes me as fragile, open ended and
> contrary to the whole idea of separating the serialization of the
> serialization library from the types it is meant to serialize.  After
> implementing serialization for all the standard library types without major
> problem, we now want to make a special case for one particular type?  Where
> does that lead us?  What about the other types in TR1?  Has anyone
> considered whether or not they expose enough of their state to permit
> serialization independent of their implemenation?
> 
> The problem I'm concerned about is adding stuff into the serialization
> library just to handle one particular type.  That creates a sort of open
> ended maintainence issue.  I would hope someone might suggest some elegant
> edition to the interface that would be guarenteed to resolve
> 

The code that needs to be added inside the serialization library is not specific 
to shared_ptr at all, or any other type for that matter. It's just the code for 
a mechanism to store object references, keyed by pointers, that can then be used 
by 3rd party programmers to serialize eg smart pointers.

> 
> I really can't know that one solution is going to work for every
> "reasonable" smart pointer. and even so it would require adding every new
> type that came along into the serialization library.  This would defeat the
> original purpose of factoring out this code into a "library"
> 

As I was saying, it's not necessary to add anything type-specific to the 
serialization library, just the basic tools so that serialization of eg 
shared_ptr can be implemented externally, externally both to shared_ptr and to 
the serialization library.

/Jarl