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

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-01-28 22:25:19

"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.

I believe that those who are part of the C++ Standards committee are making
too much of the "Standard". Standards evolve and so do languages. When they
don't, they solidify into stone instead of being a living organism of change
and while there is nothing wrong with stone, per se, it is a much harder
substance with which to work than a more malleable element. I prefer the
more malleable element and I am not personally concerned, as a C++
programmer, with the need to support code 20 and 30 years old and more.
Therefore the need to never actually offer any improvements to the C++
language itself or the need to justify every library change as something
that must last for the next 20 or 30 years, as so many committee members
seem to believe, is IMHO an unnecessary delusion.

I hope to see better smart pointers in the next version of C++ and Boost's
shared_ptr<> seems like a good candidate. If Loki's SmartPtr<> makes it in
also I see nothing wrong with that too. I just wish that members of the
commitee, and I do not mean to point my finger at you directly, would just
realize that changes to the languages and library do not have to be 100%
correct in all their ramifications for all time, but that when changes are
made they should serve the practical purpose of making the language easier
to use and program in the future.