Hi!

Is copy elision allowed for returning a function's parameter?

In other words:

  string flip(string x)
  {
     reverse( x.begin(), x.end() );
     return x; // <-- Do I need std::move() here?
  }

In N2914.pdf we can read in section 12.8/15 [class.copy] that the
elision of a copy is permitted under some circumstances including:

 - in a return statement in a function with a class return type,
   when the expression is the name of a non-volatile automatic
   object with the same cv-qualified type as the function return
   type, the copy operation can be omitted by constructing the
   automatic object directly into the function's return value

and later we can read that, if a copy elision is allowed but cannot be
performed the compiler has to treat the source object as an rvalue
when selecting a constructor for the return value. My question is
whether a function's parameter which has been accepted by value can
qualify as a "non-volatile automatic object". From what I know current
C++ implementations don't support this kind of copy elision but that
doesn't mean that it is not allowed.

In case this elision is currently deemed illegal I have to ask why
this is and whether I'm missing an obvious problem with letting the
compiler treat such parameters as rvalues in a return expression.

[N2914] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf

Cheers!
SG

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 30 Jun., 17:28, SG <s.gesem...@gmail.com> wrote:
> Is copy elision allowed for returning a function's parameter?
>
> In other words:
>
>   string flip(string x)
>   {
>      reverse( x.begin(), x.end() );
>      return x; // <-- Do I need std::move() here?
>   }
>
> In N2914.pdf we can read in section 12.8/15 [class.copy] that the
> elision of a copy is permitted under some circumstances including:
>
>  - in a return statement in a function with a class return type,
>    when the expression is the name of a non-volatile automatic
>    object with the same cv-qualified type as the function return
>    type, the copy operation can be omitted by constructing the
>    automatic object directly into the function's return value
>
> and later we can read that, if a copy elision is allowed but cannot be
> performed the compiler has to treat the source object as an rvalue
> when selecting a constructor for the return value. My question is
> whether a function's parameter which has been accepted by value can
> qualify as a "non-volatile automatic object". From what I know current
> C++ implementations don't support this kind of copy elision but that
> doesn't mean that it is not allowed.
>
> In case this elision is currently deemed illegal I have to ask why
> this is and whether I'm missing an obvious problem with letting the
> compiler treat such parameters as rvalues in a return expression.
>
> [N2914]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2914.pdf

IMO the current WP of the standard clearly says that a function
parameter can be copy-elided, if used as return value. Just read
[dcl.stc]/2:

"[..] An object declared without a storage-class-specifier at block
scope
or declared as a function parameter has automatic storage duration by
default."

so a function parameter refers to an object of automatic storage
duration.

According to [class.copy]/1:

"A class object can be copied in two ways, by initialization (12.1,
8.5),
including for function argument passing (5.2.2) and for function
value
return (6.6.3), and by assignment (5.17). Conceptually, these two
operations are implemented by a copy constructor (12.1) and copy
assignment operator (13.5.3)."

function argument passing belongs to a similar kind of class object
"mechanics" as function value returning.

Note also that the combination of [expr.call]/4

"[..] During the initialization of a parameter, an implementation may
avoid the construction of extra temporaries by combining the
conversions
on the associated argument and/or the construction of temporaries
with
the initialization of the parameter (see 12.2)."

and [class.copy]/15 b. 3

"when a temporary class object that has not been bound to a reference
(12.2) would be copied to a class object with the same cv-unqualified
type, the copy operation can be omitted by constructing the temporary
object directly into the target of the omitted copy"

and with your referenced [class.copy]/15 b. 1 provide a complete
optional optimization phase between a function call with parameters
up
to the construction of the function return value as in

std::string v = flip("Something");

HTH & Greetings from Bremen,

Daniel Kr   gler


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]