[boost] Re: Re: Re: shared_ptr and serialization

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-11-19 11:49:26

"Jonathan Wakely" <cow_at_[hidden]> wrote in message
news:20041119110911.GG9648_at_compsoc.man.ac.uk...
> On Thu, Nov 18, 2004 at 10:56:24PM -0800, Robert Ramey wrote:
>
> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > news:009001c4cd69$3bb90d60$6501a8c0_at_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