[boost] Re: Re: Re: Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-01-29 10:22:20

"Greg Colvin" <Gregory.Colvin_at_[hidden]> wrote in message
news:5.2.0.9.2.20030128210836.02818cd0_at_rgmgitmail.oraclecorp.com...
> At 08:25 PM 1/28/2003, Edward Diener wrote:
> >"Beman Dawes" <bdawes_at_[hidden]> wrote in message
> >news:4.3.2.7.2.20030128191017.0229cce8_at_mailhost.esva.net...
> >> At 01:42 PM 1/28/2003, David B. Held wrote:
> >>
> >>  >"Greg Colvin" <Gregory.Colvin_at_[hidden]> wrote in message
> >>  >news:5.2.0.9.2.20030128104737.027bcea8_at_rgmgitmail.oraclecorp.com...
> >>
> >>  >> Also, auto_ptr is an ugly hack that needn't be replicated.
> >>  >
> >>  >Disavowing your child? ;)
> >>
> >> Historical note: auto_ptr<> was one of the few (maybe only) times when
the
> >> C++ committee as a whole overrode the recommendation of the Library
> >Working
> >> Group.
> >>
> >> Greg and other people in the LWG didn't like auto_ptr<>, preferring
what is
> >> now called shared_ptr<>. But we were good soldiers, and accepted the
> >> committee's decision. That meant we had to develop auto_ptr<>, even
though
> >> we didn't like it. A lot of us still think it is a minor smart pointer,
and
> >> has no place in the standard, except perhaps as an adjunct to more
> >> important smart pointers such as shared_ptr<> and eventually
smart_ptr<>.
> >
> >Many people have used std::auto_ptr<> successfully to do what it does
best.
> >As languages and understanding evolve other, better solutions have
evolved
> >also, but that doesn't mean std::auto_ptr<> has not served its purpose or
> >will continue to do so.
>
> My problem with auto_ptr isn't so much the semantics, which
> have proved useful and are probably the minimum needed to
> solve the problem that the committee wanted solved.  And it
> isn't so much the "move as copy" syntax that Howard dislikes.
> And except on a personal level it isn't the politics that led
> to it being the way it is.  My problem is the extremely fragile
> language tricks needed to implement auto_ptr, exploiting a
> loophole on a loophole, which I don't think should be imitated
> unless really, really necessary.  I hope that in the next
> standard the language can be changed in a way that makes
> auto_ptr straightforward to implement.

OK, but the language tricks, which I am guessing centers on auto_ptr_ref,
are very well hidden from the user who understands exactly how and why a
std::auto_ptr<> should be used. In that sense it is successful rather than
in the sense of the difficulty of implementation itself. In other words, the
basic interface to using it is clear and fairly simple unless the programmer
decides not to learn it and just makes unwarranted assumptions.

I have no doubt a smarter pointer, such as Boost's shared_ptr<> and/or
Loki's SmartPtr<>, will be part of the next standard, for the simply reason
that a smart pointer which can be used in containers is an important
programming idiom. Over and above that I am sure there are other commendable
goals for a smarter pointer standard library class, but whichever smarter
pointers are chosen, the implementors should not take their eye off of the
result that makes that smart pointer clear and fairly simple for an end-user
programmer to use in its normal configuration.