Re: [boost] auto_vector - vector with auto_ptr semantics

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2002-02-05 00:09:59

From: "Howard Hinnant" <hinnant_at_[hidden]>
> On Monday, February 4, 2002, at 08:05  PM, Greg Colvin wrote:
> 
> >>  I imagine you would be
> >> one of the first to agree that giving auto_ptr move semantics was not
> >> easy, or at least not straight forward! :-)
> >
> > It was the most evil and ugly thing I was ever forced to do. ;->
> 
> </somewhat off topic>
> 
> But I feel moved to speak.
> 
> I honestly feel that auto_ptr is a pioneer.  The mother of smart 
> pointers if you will.  I have great admiration for the work that Greg 
> and Bill Gibbons did on auto_ptr, and under tremendous pressure I'm 
> sure.  I know that there were smart pointers before auto_ptr.  But 
> auto_ptr managed to satisfy the entire standards committee in 1997.  And 
> as I have gradually come to believe just over the past year, I think 
> auto_ptr is the forerunner of generalized  move semantics.  There is 
> great parallel between auto_ptr_ref and John's move_t I spoke of 
> earlier.  Greg and Bill were designing working move semantics in '97 and 
> I'm still struggling with this issue 5 years later.
> 
> My hat is off to Greg and Bill.  A job well done!  I can not imagine 
> trying to design move semantics today without auto_ptr to stand on.

<blush>

We were unwilling pioneers.  The auto_ptr originally accepted
was much simpler, because I thought the language still allowed
temporaries to bind to non-const references.  When I found out
I was wrong I switched to a version that transfered a mutable
ownership bit, but didn't zero out the source pointer.  That
version proved most unpopular, and under great time pressure
Bill Gibbons came up with the auto_ptr_ref hack, which took
advantage of some loopholes on loopholes to imitate binding to
a non-const reference.

It turns out that auto_ptr_ref doesn't quite do the job:
    http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#84

In particular, the line labeled 16 below does not compile:

                                              //  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(source());         //  9
       auto_ptr<Derived> pp(p);               // 10
       Derived::sink(source());               // 11
       p = pp;                                // 12
       p = source();                          // 13
       auto_ptr<Base> q(source());            // 14
       auto_ptr<Base> qp(p);                  // 15
       Base::sink(source());                  // 16
       q = pp;                                // 17
       q = source();                          // 18
       return p;                              // 19
       return source();
    }

For the next standard I'd like to rewrite the specification to
match the original version, but in the form of a requirements
table for an auto_ptr concept, and leave it implementors to
make it work -- perhaps via a move intrinsic or extension.