Boost logo

Boost :

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

Robert Ramey <ramey <at>> writes:

> Jarl Lindrud wrote:
> > Robert Ramey <ramey <at>> 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


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


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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at