RE: [boost] auto_vector - vector with auto_ptr semantics

From: Jon Kalb (jonkalb_at_[hidden])
Date: 2002-02-04 19:37:36

Howard,

Is move what we really want? Or is it swap? I've thought for awhile that
swap was a missing "operator." It seems to be such a fundamental
operation.

I think it is clear what swap means, but I'm not certain that it is
always going to be obvious what the state of an object is that has been
"moved from." Does it assume the state of the default value? What if
there is no default constructor? What if the default constructor does an
allocation in preparation of storing data? Would that mean that move
could fail?

Note that if auto_ptr swapped instead of moved it would have almost the
same behavior when being passed or returned. Consider returning by
auto_ptr:

auto_ptr<Foo> FooBar()
{
    auto_ptr<Foo> result(new Foo(A));
}

...
auto_ptr<Foo> dest(new Foo(B));
dest = FooBar();
...

Currently dest will delete its pointer to Foo(B) and accept the pointer
to Foo(A) from result which gives up ownership of Foo(A) and is
destructed.

With swap semantics, dest trades pointers with result and result deletes
the pointer to Foo(B) when it is destructed.

I'm not suggesting that we change the semantics of auto_ptr at this late
date. Code like this would do something the author hadn't intended:

auto_ptr<Foo> a(new Foo), b(new Foo); a = b;

What I am saying is that I think swap semantics accomplish what you want
to accomplish with move, but is "more fundamental." Herb Sutter has
convinced me that if I want to write exception safe code, I need to
create a swap operation anyway and if I could use that operation to
accomplish what you want to accomplish with move, I think it's a win.

-----Original Message-----
From: Jeremy Siek [mailto:jsiek_at_[hidden]] 
Sent: Monday, February 04, 2002 3:27 PM
To: boost_at_[hidden]
Subject: Re: [boost] auto_vector - vector with auto_ptr semantics

Nice description and motivation for move semantics.

On Mon, 4 Feb 2002, Howard Hinnant wrote:
hinnan>
hinnan> What remains to be done is to settle on a uniform syntax for
move
hinnan> semantics.  John Maddock has suggested:
hinnan>
hinnan> T b = std::move(a);

Would this mean we'd also have to rely on cooperation from operator=?
Wouldn't it be better to keep things simple with something like this
instead:

std::move(a, b);  // a -> b

hinnan> Perhaps boost::auto_vector could experiment with this.  The big
hinnan> stumbling block I've had to date is allowing move from a
temporary T,
hinnan> but disallowing move from a const T, and packaging this up in a
hinnan> relatively reusable package so that giving your class move
semantics is
hinnan> no harder than giving it copy semantics.

Well, non-const member functions have the property that you can call
them
on temporaries but not on const objects. So you could do this:

a.move_to(b);

Of course, this would require invasive changes to current classes, and
couldn't have the same syntax for builtins.

Or perhaps we just need to file a DR to once again allow temporaries to
be
bound to non-const references. On the surface that restriction made a
lot
of sense, but deep down it was wrong.

Cheers,
Jeremy

----------------------------------------------------------------------
 Jeremy Siek                          http://php.indiana.edu/~jsiek/
 Ph.D. Student, Indiana Univ. B'ton   email: jsiek_at_[hidden]
 C++ Booster (http://www.boost.org)   office phone: [phone]
----------------------------------------------------------------------

Info: http://www.boost.org  Send unsubscribe requests to:
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/