Re: [boost] auto_vector - vector with auto_ptr semantics

From: Rainer Deyke (root_at_[hidden])
Date: 2002-02-04 21:18:14

----- Original Message -----
From: "Howard Hinnant" <hinnant_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, February 04, 2002 5:08 PM
Subject: Re: [boost] auto_vector - vector with auto_ptr semantics

> On Monday, February 4, 2002, at 06:25  PM, Rainer Deyke wrote:
>
> > What about return-by-move?  I see two possibilities:
> >
> > 2. Let the compiler handle it automatically:
> >
> >   T f()
> >   {
> >     T a;
> >     return a;
> >   }
> >
> >   T b(f());
> >
> > Here the compiler realizes that 'a' will be destroyed immediately
> > after 'b' is constructed, so it uses the movement constructor
instead
> > of the copy constructor if both are available.
>
> Actually I believe the standard already allows return value
optimization
> to make:
>
> T b(f());
>
> work as desired.

In theory the compiler is allowed to do anything at all so long as
outward semantics are preserved, but in practice there are cases where
a move-constructor is necessary for performance.  'f' right now is
pretty trivial, but consider a less trivial example:

std::vector<int> g()
{
  std::vector<int> first, second;
  // Do various operations on 'first' and 'second' here.
  return (first.size() > second.size()) ? first : second;
}

std::vector<int> v(g());

The compiler can't construct the return value "in place" because it
does not know which of the two vectors will be returned at the time of
construction.

>  But here's another possibility in case your compiler
> is weak in this area:
>
> T b(std::move(f()));
>
> (assuming we can get the move from temporary worked out)

I don't think this will work because by the time 'f' returns, the
temporary will already be copied.

--
Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com