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