Robert Ramey <ramey <at> rrsd.com> writes:
martin.ecker <at> tab.at wrote:
also the fact that a special export macro BOOST_SHARED_POINTER_EXPORT is needed to export classes used with shared_ptr. It's especially cumbersome when shared_ptr is used polymorphically, i.e. we use shared_ptr<Base> that actually points to an instance of class Derived.
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.
As was discussed before, a good way to achieve this is to use a pointer-to-shared_ptr map in the input archive when loading archives that contain shared_ptrs. This is actually the approach that we've hacked into the version of boost::serialization here at work. We've been using it for a couple of months now like this and have not experienced any problems with it.
Gee, wouldn't it have been easier just to add a friend to the share_ptr?
And it also works for serializing weak_ptr.
However, I would really appreciate an 'official' solution to shared_ptr (and weak_ptr) serialization.
Me too - but I can't see how this is going to happen
Robert Ramey
Why can't it happen? There was a thread on this a while back, presenting the same solution as above. Is there a particular reason why that approach wasn't taken? Was it ever considered? I've implemented it myself, both in my own serialization framework (http: //tinyurl.com/3nhmc), and on top of boost's, and it's pretty simple. 100% external serialization, and it would work with just about any reference-counted smart pointer. No extra registration macros needed either. The way it's done now just seems very heavy handed to me, and doing it that way for every smart pointer that might come along, eg in std::tr1, is not even feasible. Since its possible to serialize a shared_ptr, or any reasonable smart pointer for that matter, from its corresponding public interface, why not do it? /Jarl PS Thanks for an otherwise great library! shared_ptr's are my only gripe :)