Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at