Re: Re: Re: shared_ptr and serialization
Honestly, I don't need to serialize std::tr1::shared_ptr - why would any of us ever use it as long as we have boost::shared_ptr which (with serialization is a superset of std::tr1::shared_ptr.)
That's a completely bogus argument.
I understand your objection to boost::serialization depending upon the implementation details of boost::shared_ptr. I just don't see any way to address this other than making big changes to either the serialization libary or shared_ptr. Even then, its not obvious to me that its even possible.
Doesn't Peter's own serialization library succeed in not requiring special access to boost::shared_ptr? If so, it is an existence proof that there's a way to do it, which I think means that big changes may need to be made to Boost.Serialization. It will be a reasonable expectation for a Boost.Serialization user to serialize std::tr1::shared_ptrs in the future. Has Peter described the algorithm he used? Dave
"Dave Gomboc" <dave@cs.ualberta.ca> wrote in message news:Pine.LNX.4.44.0411200014060.15771-100000@opal.cs.ualberta.ca...
Honestly, I don't need to serialize std::tr1::shared_ptr - why would any of us ever use it as long as we have boost::shared_ptr which (with serialization is a superset of std::tr1::shared_ptr.)
That's a completely bogus argument.
what's bogus about it? As a practical matter if one has boost serialization one has boost::std_ptr. A question - is it possible to add a facility that would convert between std::tr1:shared_ptr and boost::shared_ptr via their public interfaces? My guess its that its not. I'm just curious.
I understand your objection to boost::serialization depending upon the implementation details of boost::shared_ptr. I just don't see any way to address this other than making big changes to either the serialization libary or shared_ptr. Even then, its not obvious to me that its even possible.
Doesn't Peter's own serialization library succeed in not requiring special access to boost::shared_ptr? If so, it is an existence proof that there's a way to do it,
I recall only seeing portions of this library in this discussion thread. I don't know how it compares to the current boost serialization library. So I'm not sure that constitutes an existence proof.
which I think means that big changes may need to be made to Boost.Serialization.
Hmmm - at what cost? what if this requirement conflicted with other requiremetns of the serialization library? For example, what if serializing though the public interface of shared_ptr required eliminating ability to serialize polymorphic pointers? would this be worth it? How can one reach such a conclusion without considering issues such as this?
It will be a reasonable expectation for a Boost.Serialization user to serialize std::tr1::shared_ptrs in the future.
This is not in dispute - the question is it doable iand if so, at what cost. So far this is the only std::library component that cannot be serialized via it's public interface. I doubt that any serialization library available today (and there many) could implement serialization of std::tr1::shared_ptr from its pubilc interface. Perhaps this suggests that there is something missing from std::tr1::shared_ptr ?
Has Peter described the algorithm he used?
we've seen some code snipets on this thread. I don't know what else may be available. Robert Ramey
Robert Ramey wrote:
I doubt that any serialization library available today (and there many) could implement serialization of std::tr1::shared_ptr from its pubilc interface. Perhaps this suggests that there is something missing from std::tr1::shared_ptr ?
I recently came across genserial.sf.net. Take a look if you have the time, it uses shared_ptr extensively. Quite impressive use of custom deleters and the like. ;-)
participants (3)
-
Dave Gomboc -
Peter Dimov -
Robert Ramey