"Jonathan Wakely" <cow@compsoc.man.ac.uk> wrote in message news:20041119110911.GG9648@compsoc.man.ac.uk...
On Thu, Nov 18, 2004 at 10:56:24PM -0800, Robert Ramey wrote:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:009001c4cd69$3bb90d60$6501a8c0@pdimov2...
Robert Ramey wrote:
So maybe we can consider a practical compromise.
a) Grant me access to the internals of shared_ptr for now
a) You aren't going to get access to the internals of std::tr1::shared_ptr.
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.)
By "us" I assume you mean the Boost developers. Do you suppose that the Boost developers are the only, or even typical, users of Boost?
By "us" I meant a user of boost libraries. A user of boost libraries has access to boost::shared_ptr as well as boost::serialization .
One day std::tr1 will come provided with most standard libraries, and there might be reasons it is preferred in some projects to the boost versions.
If one of those projects wanted to use the Boost serialization library would they have to switch to boost::shared_ptr ?
At this point yes since the std::tr1::shared_ptr doesn't make any provision for its serialization. And no one has figured out how to do it based soley on its public interface.So far its the only standard library component that anyone has wanted to serialize that hasn't been possible from its public interface. Maybe the advocates of std::tr1::shared_ptr have to spend some more time thinking about this. As an aside - this reinforces my personal reservations that standardization of library components that are solely dependent on the language is not a great idea. Personally, I think we would be better served to limit these efforts to those library facilities meant to abstract away platform differences.
Even if you can't think of a good reason, do you suppose that means there isn't one?
I didn't suppose anything - I just asked the question. If someone knows a good reason I would like to hear it.
How about a large system that must have no external requirements in some components, so Boost cannot be used, but std::tr1::shared_ptr is used.
If boost cannot be used - boost serialization cannot be used so there is no issue here as far as boost serialization is concerned.
One isolated part of this system wants to use Boost.Serialization, but finds that to do so would require that the entire system be switched to use boost::shared_ptr.
Its hard to know without a specific case. Its very common for me to have boost in some modules and not in others. (Actually, this is the usual case for me).
I don't have any other opinion on the subject, I just wanted to point out what I thought was rather presumptuous.
Opinion noted. Robert Ramey