Re: [boost] Re: shared_ptr comparison

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-08-20 14:33:48

On Monday, August 6, 2001, at 02:28  PM, Greg Colvin wrote:

> I put "broke" in quotes, as what they did was on the edge
> between "breaking" and "refusing to fix".  In brief, Bill
> Gibbons' rescued auto_ptr at the last moment by coming up
> with a very clever implementation to allow the auto_ptr
> to have it's bizzare copy semantics by using (some say
> abusing) some obscure loopholes in the language.

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.

</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/>

I would love to see move semantics and syntax standardized, and auto_ptr 
(perhaps under another name) seems like a good place to start.

#include <memory>                         //  1
struct Base {                             //  2
    static void sink(auto_ptr<Base>);      //  3
};                                        //  4
struct Derived : Base {                   //  5
    static void sink(auto_ptr<Derived>);   //  6
};                                        //  7
auto_ptr<Derived> source() {              //  8
    auto_ptr<Derived> p(move(source()));         //  9
    auto_ptr<Derived> pp(move(p));               // 10
    Derived::sink(move(source()));               // 11
    p = move(pp);                                // 12
    p = move(source());                          // 13
    auto_ptr<Base> q(move(source()));            // 14
    auto_ptr<Base> qp(move(p));                  // 15
    Base::sink(move(source()));                  // 16
    q = move(pp);                                // 17
    q = move(source());                          // 18
    return p;                              // 19
}

> or perhaps specify auto_ptr in terms of semantics with
> no mention of auto_ptr_ref, and tell implementers to just "make
> it so".

I believe that we will discover that move() is really just a generalized 
auto_ptr_ref.  And I also think that move() could be a significant 
performance win when generalized to other objects, especially in the 
context of containers of containers (e.g. vector<string>).  Indeed, if 
vector understood and could detect move semantics (and if auto_ptr 
didn't pretend to have copy semantics), I think vector<auto_ptr<T> > 
could even become acceptable again.

Of course, backward compatibility is our biggest problem.  Thus this 
little gem perhaps could not be named auto_ptr.

-Howard