Optimized return value

[normvcr]

There has been lots of discussion and compiler experiments with optimizing the return value from a C++ function, specifically to reduce the number of copy constructors and temporaries that are needed. The following idea seems reasonable and safe, so I am wondering whether this has been considered.

// A class of some size
class A{ int ivar; double dvar; };

// A function returning an object of class A.
A f( void ) 
{
  A avar;
  return avar;
}

The idea is to tell the compiler to construct the A object not on the stack, so the that return statement does not have to invoke a copy constructor. For example, the declaration of avar could make a new use of the "virtual" keyword:

virtual A avar;

In this case, the compiler is being told to construct avar in the same kind of memory wher the compiler would build a temporary object. The compiler will decide when to deallocate the object. Since the A object has been constructed outside of memory "owned" by the function, a copy constructor is not needed to realize the return value.

A related precedent is to use "static" instead of "virtual", which tells the compiler to allocate the A object in persistent memory (in fact, allocated at most once in each process).

[JLBorges]

> There has been lots of discussion and compiler experiments
> with optimizing the return value from a C++ function

Yes, before 1998.
http://en.wikipedia.org/wiki/Return_value_optimization

[Cubbi]

There's also a fairly detailed explanation at http://en.cppreference.com/w/cpp/language/copy_elision

[normvcr]

Thanks for the pointers. Always an interesting read.
The point that I should have made more clearly, is for the ability to instruct the compiler to elide the copy constructor by using, say, a new keyword, as described, above. The current problem, is that the compiler may or may not do this, and side effects will or will not occur, depending on what the compiler chooses i.e. an inconsistent formulation of the program.

If the compiler is not able to do the elision, then a warning/error would be emitted, bringing this to the attention of the programmer. A work-around, to avoid this ambiguity, is, I believe, to quality the declaration of A with "volatile"

volatile A avar;

The problem, here, of course, is that the optimization does not occur.

[Cubbi]

to instruct the compiler to elide the copy constructor

You do that by fulfilling the requirements for copy elision (returning a local object that's not a function argument, for example).

A new keyword would be as redundant as the now-deprecated keyword register, since it would not change the semantics of the program (not to be confused with register in C, which prohibits address-of).

What would be helpful, probably, is a debug mode option that disables all copy elisions: gcc has one, Visual Studio doesn't (and performs URVO and some other elisions in debug mode)

If the compiler is not able to do the elision, then a warning/error would be emitted

That would indeed be a nice diagnostic option. In my opinion, a missed elision opportunity is a compiler bug, and this would help spot them.