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? 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 ? Even if you can't think of a good reason, do you suppose that means there isn't one? 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. 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. I don't have any other opinion on the subject, I just wanted to point out what I thought was rather presumptuous. jon -- "Because the only people for me are the mad ones, the ones who are mad to live, mad to talk, mad to be saved, desirous of everything at the same time, the ones who never yawn or say a commonplace thing, but burn, burn, burn like fabulous yellow roman candles exploding like spiders across the stars and in the middle you see the blue centerlight pop and everybody goes "Awww!" - Jack Kerouac