Re: Re: shared_ptr comparison

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-08-22 05:26:35

>   From: John Max Skaller <skaller_at_[hidden]>
>Howard Hinnant wrote:
>
>> I see what Greg says in a different light.  I don't think auto_ptr has
>> bizzare copy semantics.  In fact I don't think auto_ptr has /any/ copy
>> semantics.  auto_ptr is not copyable.  I think it has move semantics.
>> Unfortunately the syntax for auto_ptr's move semantics has the syntax of
>> copy.  And *that* is where the confusion lies.
>
>       I agree completely. Actually, the name 'auto_ptr' is misleading
>(since 'auto' means 'on the stack'), so that's another confusion.

Violent agreement: bad name and subtle semantics. Both of these features
make it a pain to teach at anything other than a trivial level. Time was
(before we had the standard) when you could get students new to C++ to
implement auto_ptr as an exercise towards the end of an introductory
course. Now it takes as much effort, if not more, just describing how to
use it!

>       However, I'd go further. The use of copy syntax for a move
>semantics isn't just confusing: its a design fault.

Yes, definitely.

>       The problem is, there's no syntax for move: the idea
>doesn't make any sense in C, and the closest thing C++ has
>is a method call .. which doesn't express the relationship
>between the source and target correctly.

But at least a function call expresses the intention more clearly than
the misuse of an existing syntax. If nothing else, it's a better
starting point.

>> </philosophical on/>
>> Fwiw I think auto_ptr has been a tremendous success in any event.  It
>> has been like a lighthouse in the fog; both showing us the way, and
>> warning us of the nearby rocks.  auto_ptr may not be perfect (what code
>> is?), but I think it will go down as one of the great pieces of the C++
>> lib.
>> </philosophical off/>
>
>       It is the first component I would drop, if I had a choice. :-)

I agree -- it's either that or allocators :-> What is has shown us is
the value of separating concerns rather than overloading one poor
component with so many different roles. The fact that scoped_ptr does
not do everything that auto_ptr does is one of its greatest strengths:
it is small and cohesive. It does one thing well, and is unlikely to be
broken by core language changes :->

So, one size certainly does not fit all, and the need for a family of
smart pointers is clear. That this is the more appropriate solution has
been demonstrated in many libraries, and not just Boost. However, Boost
is well placed to influence the future development of the C++ standard.
The feature model for smart pointers that Beman drew up last year of
smart pointers does a good job of trying to map out this territory.
Perhaps it is time to start thinking about Boost smart pointer move
semantics in more detail?

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________