Boost logo

Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-21 16:12:10

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.

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

        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.
> </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 would love to see move semantics and syntax standardized,

        We could argue about the semantics: but have you ANY
ideas at all for a syntax??

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

        Irrelevant. There's no backwards compatibility problem
with move semantics represented by a new syntax. The problem
is finding the syntax.

        I suspect it is not possible. The reason is the
way C/C++ scoping rules work. Here's the correct semantics
for a move:

        The object 'src' is in scope.
        The object 'dst' is declared, takes the value of src,
                and 'src' goes out of scope.

the reason this is correct is that it is impossible to
refer to 'src' after its value is moved to 'dst',
and of course impossible to refer to 'dst' before it is declared.
[Of course, this assumes no aliasing with pointers]

        So we need a syntax like:

        decl int x = 1 in .... use x here ..
        move y in ... use y here

There's no way to call a function with this kind of
syntax. The conclusion is that calling a function
is wrong: move semantics are associated not with
a SUBroutine but with a COroutine. That is,
to have a move operator, it applies to control
as well: an exchange of control is a coroutine call.

The closest syntactic model for this in C++ is multiple

        struct left { int x; void f() { .. x .. } }
        struct right { int y; void f() { .. y .. ] }
        struct both : left, right {
                void f() {

Here, you can interleave methods from left and right in both's
methods, and the left and right methods execute in their
own scopes. Here, if you can 'move' a value between such
interleaved method calls, the move is safe:

        both::f() {
        auto_ptr tmp = init;
        tmp = left::f1(tmp);
        tmp = right::f1(tmp);
        tmp = left::f2(tmp);
        tmp = right::f2(tmp);
So it 'remains' to combine the data structure and control
structure into a single entity -- and THAT would be a suitable
syntax for a move semantics.

Summary: moving data must be associated with exchanging
control between coroutines. Hence, there is no syntax
for move in C/C++ because there are no coroutines.
The situation cannot be fixed without adding coroutines
because move semantics do not make sense otherwise.

[this is a proposition for discussion, not a strongly held belief!]

John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix
Literate Programming tool Interscript

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