I have two pieces of code here to show you. They are two classes and each one provides a Move Constructor and a function which returns a temporary.
In the first case, the function returning a temporary calls the Move Constructor
In the second case, the function returning a temporary just tells the compiler to perform a copy elision
I'm confused: in both cases I define a Move Constructor and a random member function returning a temporary. But the behavior changes, and my question is why.
Note that in the following examples, the operator<< was overloaded in order to print a list (in the first case) and the double data member (in the second case).
MOVE CONSTRUCTOR GETS CALLED
template<typename T>
class GList
{
public:
GList() : il{ nullptr } {}
GList(const T& val) : il{ new Link<T>{ val,nullptr } } {}
GList(const GList<T>& copy) {}
GList(GList<T>&& move)
{
std::cout << "[List] Move constructor called" << std::endl;
// ... code ...
}
// HERE IS THE FUNCTION WHICH RETURNS A TEMPORARY!
GList<T> Reverse()
{
GList<T> result;
if (result.il == nullptr)
return *this;
...
...
...
return result;
}
};
int main()
{
GList<int> mylist(1);
mylist.push_head(0);
cout << mylist.Reverse();
return 0;
}
The output is:
[List] Move constructor called
0
1
COPY ELISION PERFORMED
class Notemplate
{
double d;
public:
Notemplate(double val)
{
d = val;
}
Notemplate(Notemplate&& move)
{
cout << "Move Constructor" << endl;
}
Notemplate(const Notemplate& copy)
{
cout << "Copy" << endl;
}
Notemplate Redouble()
{
Notemplate example{ d*2 };
return example;
}
};
int main()
{
Notemplate my{3.14};
cout << my.Redouble();
return 0;
}
The output is:
6.28
I was expecting a call to the Move Constructor in the second example.
After all, the logic for the function is the same: return a temporary.
Will someone explain me why that's not happening?
How do I deal with copy elisions?
I want my code to be the most portable I can, how can I be sure of these kinds of optimizations by the compiler?
In the comments of another SO answer, the OP clarifies what he is asking here:
I heard that copy elision CAN occur even when there are more than 1
return statements. I'd like to know when a copy elision is forbidden
And so I am attempting to address this issue here:
Elision of copy/move operations (referred to as copy elision by the C++ standard) is permitted in the following circumstances:
In a return statement in a function with a class return type, when the expression is the name of anon-volatile object with automatic storage duration (other than a function parameter or a variable introduced by the exception-declaration of a handler) with the same type (ignoring cv-qualification) as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value.
In a throw-expression, when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy/move operation from the operand to the exception object can be omitted by constructing the automatic object directly into the exception object.
When a temporary class object that has not been bound to a reference would be copied/moved to a class object with the same type (ignoring cv-qualification), the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move.
When the exception-declaration of an exception handler declares an object of the same type (except for cv-qualification) as the exception object, the copy operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration. There cannot be a move from the exception object because it is always an lvalue.
Copy elision is forbidden in all other circumstances.
The number of return statements in a function has no bearing whatsoever on the legality of copy elision. However a compiler is permitted to not perform copy elision, even though it is legal, for any reason at all, including the number of return statements.
C++17 Update
There are now a few places where copy elision is mandatory. If a prvalue can be bound directly to a by-value function parameter, or a by-value return type, or to a named local variable, copy elision is mandatory in C++17. This means that the compiler shall not bother even checking for a copy or move constructor. Legal C++17:
struct X
{
X() = default;
X(const X&) = delete;
X& operator=(const X&) = delete;
};
X
foo(X)
{
return X{};
}
int
main()
{
X x = foo(X{});
}
The copy elision is an optimization that, nowadays, every modern compiler provides.
When returning huge class objects in C++, this technique applies... but not in every case!
In the first example, the compiler performs the Move Constructor because we have more than one return statement in the function.
Related
Lets say I have a class node with copy, move constructor, default constructor
Node func (Node n){
return n;
}
Node newN = func(Node{}); //#2
Then how many times are these called?
Move constuctor: once at #2.
What about copy constructor?
At best one construction and one move construction.
#include <iostream>
using std::cout;
using std::endl;
class Something {
public:
Something() {
cout << __PRETTY_FUNCTION__ << endl;
}
Something(Something&&) {
cout << __PRETTY_FUNCTION__ << endl;
}
Something(const Something&) {
cout << __PRETTY_FUNCTION__ << endl;
}
};
Something foo(Something in) {
return in;
}
int main() {
Something something = foo(Something{});
(void) something;
}
The output for the above is this
Something::Something()
Something::Something(Something &&)
The construction of the Something object results in a prvalue, which is a candidate for RVO, this will be elided into the function parameter for foo(). If you compile with C++17 this will be elided no matter what, but when you compile with C++11 and C++14 this will be elided only if elisions are not disallowed with the -fno-elide-constructors compilation flag.
However when you return that object from the function, NRVO isn't allowed to happen by the standard. Eliding from function parameters is explicitly disallowed (see below for the exact quote from the standard). So a move happens (assuming you have a move constructor, if you don't have a move constructor then a copy will take place)
So in total with elisions allowed you have one construction and one move construction (if no move constructor is defined then you get a copy)
§ 15.8.3 Copy/move elision [class.copy.elision]
When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, ...
in a return statement in a function with a class return type, when the expression is the name of a non-volatile automatic object (other than a function parameter or a variable introduced by the exception-declaration of a handler (18.3)) with the same type (ignoring cv-qualification) as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function call’s return object
As you can see the language disallows elision from function parameters, so a move happens.
Also note that if you delete the move constructor explicitly, this code will not compile
Suppose we have this class:
class X {
public:
explicit X (char* c) { cout<<"ctor"<<endl; init(c); };
X (X& lv) { cout<<"copy"<<endl; init(lv.c_); };
X (X&& rv) { cout<<"move"<<endl; c_ = rv.c_; rv.c_ = nullptr; };
const char* c() { return c_; };
private:
void init(char *c) { c_ = new char[strlen(c)+1]; strcpy(c_, c); };
char* c_;
};
and this sample usage:
X x("test");
cout << x.c() << endl;
X y(x);
cout << y.c() << endl;
X z( X("test") );
cout << z.c() << endl;
The output is:
ctor
test
copy
test
ctor <-- why not move?
test
I am using VS2010 with default settings. I'd expect the last object (z) to be move-constructed, but it's not! If I use X z( move(X("test")) ); then the last lines of the output are ctor move test, as I'd expect. Is it a case of (N)RVO?
Q: Should the move-ctor be called according to the standard? If so, why isn't it called?
What you are seeing is copy elision, which allows the compiler to directly construct a temporary into a target it is to be copied/moved into and thus elide a copy (or move) constructor/destructor pair. The situations in which the compiler is allowed to apply copy elision are specified in §12.8.32 of the C++11 standard:
When certain criteria are met, an implementation is allowed to omit
the copy/move construction of a class object, even if the copy/move
constructor and/or destructor for the object have side effects. In such
cases, the implementation treats the source and target of the omitted
copy/move operation as simply two different ways of referring to the
same object, and the destruction of that object occurs at the later of
the times when the two objects would have been destroyed without the
optimization. This elision of copy/move
operations, called copy elision, is permitted in the following
circumstances (which maybe combined to eliminate multiple copies):
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-unqualified type as the function return type, the
copy/move operation can be omitted by constructing the automatic
object directly into the function’s return value
in a throw-expression, when the operand is the name of a non-volatile automatic object whose scope does not extend beyond
the end of the innermost enclosing try-block (if there is one), the
copy/move operation from the operand to the exception object (15.1)
can be omitted by constructing the automatic object directly into
the exception object
when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with he
same cv-unqualified type, the copy/move operation can be omitted by
constructing the temporary object directly into the target of the
omitted copy/move
when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as
the exception object (15.1), the copy/move operation can be omitted
bytreatingthe exception-declaration as an alias for the exception
object if the meaning of the program will be unchanged except for the
execution of constructors and destructors for the object declared by
the exception-declaration.
The ctor output you get in your third code line is for the construction of the temporary object. After that, indeed, the temporary is moved into the new variable z. In such a situation the compiler may choose to elide the copy/move, and it seems that is what it did.
The Standard states:
(§12.8/31) When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. [...] This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
[...]
- when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
[...]
One important condition is that the source object and the destination are of the same type (apart from cv-qualification, i.e. things like const).
Therefore, one way you can force the move constructor to be called is to combine the object initialization with implicit type conversion:
#include <iostream>
struct B
{};
struct A
{
A() {}
A(A&& a) {
std::cout << "move" << std::endl;
}
A(B&& b) {
std::cout << "move from B" << std::endl;
}
};
int main()
{
A a1 = A(); // move elided
A a2 = B(); // move not elided because of type conversion
return 0;
}
You are calling X's char* constructor X("test") explicitly.
Therefore it is printing ctor
Is it possible to write C++ code where we rely on the return value optimization (RVO) when possible, but fall back on move semantics when not? For example, the following code can not use the RVO due to the conditional, so it copies the result back:
#include <iostream>
struct Foo {
Foo() {
std::cout << "constructor" << std::endl;
}
Foo(Foo && x) {
std::cout << "move" << std::endl;
}
Foo(Foo const & x) {
std::cout << "copy" << std::endl;
}
~Foo() {
std::cout << "destructor" << std::endl;
}
};
Foo f(bool b) {
Foo x;
Foo y;
return b ? x : y;
}
int main() {
Foo x(f(true));
std::cout << "fin" << std::endl;
}
This yields
constructor
constructor
copy
destructor
destructor
fin
destructor
which makes sense. Now, I could force the move constructor to be called in the above code by changing the line
return b ? x : y;
to
return std::move(b ? x : y);
This gives the output
constructor
constructor
move
destructor
destructor
fin
destructor
However, I don't really like to call std::move directly.
Really, the issue is that I'm in a situation where I absolutely, positively, can not call the copy constructor even when the constructor exists. In my use case, there's too much memory to copy and although it'd be nice to just delete the copy constructor, it's not an option for a variety of reasons. At the same time, I'd like to return these objects from a function and would prefer to use the RVO. Now, I don't really want to have to remember all of the nuances of the RVO when coding and when it's applied an when it's not applied. Mostly, I want the object to be returned and I don't want the copy constructor called. Certainly, the RVO is better, but the move semantics are fine. Is there a way to the RVO when possible and the move semantics when not?
Edit 1
The following question helped me figure out what's going on. Basically, 12.8.32 of the standard states:
When the criteria for elision of a copy operation are met or would be
met save for the fact that the source object is a function parameter,
and the object to be copied is designated by an lvalue, overload
resolution to select the constructor for the copy is first performed
as if the object were designated by an rvalue. If overload resolution
fails, or if the type of the first parameter of the selected
constructor is not an rvalue reference to the object’s type (possibly
cv-qualified), overload resolution is performed again, considering the
object as an lvalue. [ Note: This two-stage overload resolution must
be performed regardless of whether copy elision will occur. It
determines the constructor to be called if elision is not performed,
and the selected constructor must be accessible even if the call is
elided. —end note ]
Alright, so to figure out what the criteria for a copy elison are, we look at 12.8.31
in a return statement in a function with a class return type, when the
expression is the name of a non-volatile automatic object (other than
a function or catch-clause parameter) with the same cvunqualified type
as the function return type, the copy/move operation can be omitted by
constructing the automatic object directly into the function’s return
value
As such, if we define the code for f as:
Foo f(bool b) {
Foo x;
Foo y;
if(b) return x;
return y;
}
Then, each of our return values is an automatic object, so 12.8.31 says that it qualifies for copy elison. That kicks over to 12.8.32 which says that the copy is performed as if it were an rvalue. Now, the RVO doesn't happen because we don't know a priori which path to take, but the move constructor is called due to the requirements in 12.8.32. Technically, one move constructor is avoided when copying into x. Basically, when running, we get:
constructor
constructor
move
destructor
destructor
fin
destructor
Turning off elide on constructors generates:
constructor
constructor
move
destructor
destructor
move
destructor
fin
destructor
Now, say we go back to
Foo f(bool b) {
Foo x;
Foo y;
return b ? x : y;
}
We have to look at the semantics for the conditional operator in 5.16.4
If the second and third operands are glvalues of the same value
category and have the same type, the result is of that type and value
category and it is a bit-field if the second or the third operand is a
bit-field, or if both are bit-fields.
Since both x and y are lvalues, the conditional operator is an lvalue, but not an automatic object. Therefore, 12.8.32 doesn't kick in and we treat the return value as an lvalue and not an rvalue. This requires that the copy constructor be called. Hence, we get
constructor
constructor
copy
destructor
destructor
fin
destructor
Now, since the conditional operator in this case is basically copying out the value category, that means that the code
Foo f(bool b) {
return b ? Foo() : Foo();
}
will return an rvalue because both branches of the conditional operator are rvalues. We see this with:
constructor
fin
destructor
If we turning off elide on constructors, we see the moves
constructor
move
destructor
move
destructor
fin
destructor
Basically, the idea is that if we return an rvalue we'll call the move constructor. If we return an lvalue, we'll call the copy constructor. When we return a non-volatile automatic object whose type matches that of the return type, we return an rvalue. If we have a decent compiler, these copies and moves may be elided with the RVO. However, at the very least, we know what constructor is called in case the RVO can't be applied.
When the expression in the return statement is a non-volatile automatic duration object, and not a function or catch-clause parameter, with the same cv-unqualified type as the function return type, the resulting copy/move is eligible for copy elision. The standard also goes on to say that, if the only reason copy elision was forbidden was that the source object was a function parameter, and if the compiler is unable to elide a copy, the overload resolution for the copy should be done as if the expression was an rvalue. Thus, it would prefer the move constructor.
OTOH, since you are using the ternary expression, none of the conditions hold and you are stuck with a regular copy. Changing your code to
if(b)
return x;
return y;
calls the move constructor.
Note that there is a distinction between RVO and copy elision - copy elision is what the standard allows, while RVO is a technique commonly used to elide copies in a subset of the cases where the standard allows copy elision.
Yes, there is. Don't return the result of a ternary operator; use if/else instead. When you return a local variable directly, move semantics are used when possible. However, in your case you're not returning a local directly -- you're returning the result of an expression.
If you change your function to read like this:
Foo f(bool b) {
Foo x;
Foo y;
if (b) { return x; }
return y;
}
Then you should note that your move constructor is called instead of your copy constructor.
If you stick to returning a single local value per return statement then move semantics will be used if supported by the type.
If you don't like this approach then I would suggest that you stick with std::move. You may not like it, but you have to pick your poison -- the language is the way that it is.
In C++, when initializing a class like
MyClass(myBigObject s):
s_(s)
{
...
}
it looks as if s is copied once at function entry ("pass by value") and once when being assigned to s_.
Are compilers smart enough to strip out the first copy?
Compilers are allowed to strip out the first copy iff
The copy does not have observable behavior according to the as-if rule.
For this rule to apply, your compiler must know neither constructor nor destructor of myBigObject have any observable side-effects when compiling the user of the MyClass ctor.
1.9 Program Execution
The semantic descriptions in this International Standard define a parameterized nondeterministic abstract
machine. This International Standard places no requirement on the structure of conforming implementations.
In particular, they need not copy or emulate the structure of the abstract machine. Rather, conforming
implementations are required to emulate (only) the observable behavior of the abstract machine as explained
below.
or if they can use the copy-elision rule, which allows disregarding the as-if rule.
For this to apply, you must feed the constructor an anonymous unbound object.
12.8 Copying and Moving class objects §31
When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. In such cases, the implementation treats the source and target of the omitted copy/move operation as simply two different ways of referring to the same object, and the destruction of that object occurs at the later of the times when the two objects would have been destroyed without the optimization.123 This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
— in a return statement in a function with a class return type, when the expression is the name of a
non-volatile automatic object (other than a function or catch-clause parameter) with the same cvunqualified type as the function return type, the copy/move operation can be omitted by constructing the automatic object directly into the function’s return value
— in a throw-expression, when the operand is the name of a non-volatile automatic object (other than a function or catch-clause parameter) whose scope does not extend beyond the end of the innermost
enclosing try-block (if there is one), the copy/move operation from the operand to the exception
object (15.1) can be omitted by constructing the automatic object directly into the exception object
— when a temporary class object that has not been bound to a reference (12.2) would be copied/moved
to a class object with the same cv-unqualified type, the copy/move operation can be omitted by
constructing the temporary object directly into the target of the omitted copy/move
— when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as the exception object (15.1), the copy/move operation can be omitted by treating the exception-declaration as an alias for the exception object if the meaning of the program will be unchanged except for the execution of constructors and destructors for the object declared by the exception-declaration.
Far easier to take the argument by movable-reference &&, which allows replacing the second copy with a move under any circumstances.
First copy into s can be omitted for a temporary
An optimizing compiler will likely omit the first copy if you pass a temporary object:
MyClass x{ myBigObject() };
This is likely to invoke the copy constructor only once since the temporary myBigObject will be constructed directly into the constructor argument s.
Note that this can change the observable behaviour of your program.
#include <iostream>
struct myBigObject
{
size_t x;
myBigObject() : x() {}
myBigObject(myBigObject && other)
{
std::cout << "Move myBigObject" << std::endl;
}
myBigObject(const myBigObject &other)
{
std::cout << "Copy myBigObject" << std::endl;
x = 12;
}
};
struct MyClass
{
MyClass(myBigObject s)
: s_(s)
{
std::cout << "x of s : " << s.x << std::endl;
std::cout << "x of s_ : " << s_.x << std::endl;
}
myBigObject s_;
};
int main()
{
std::cout << "A:" << std::endl;
MyClass x{ myBigObject() };
std::cout << "B:" << std::endl;
myBigObject y;
MyClass z{ y };
}
It prints (https://ideone.com/hMEv1W + MSVS2013,Toolsetv120)
A:
Copy myBigObject
x of s : 0
x of s_ : 12
B:
Copy myBigObject
Copy myBigObject
x of s : 12
x of s_ : 12
Second copy into s_ cannot be elided
The copy into s_ cannot be omitted since s and s_ need to be different objects.
If you want only one copy of myBigObject in your class you can go for:
MyClass(myBigObject const & s)
: s_(s)
{
}
MyClass(myBigObject && s)
: s_(std::forward<myBigObject>(s))
{
}
This way you do not see any copies in case of the temporary and only one copy for non-temporary objects.
The altered code will print:
A:
Move myBigObject
B:
Copy myBigObject
compiler cannot optimize copying from argument to calss field in general case. Apparently your object can have complex copy constructor with side effects that cannot be omited.
But in your case you probably want to replace copying with moving.
You should write move constructor and use std::move to move s to _s:
myBigObject(myBigObject&&other);
MyClass(myBigObject s):
s_(std::move(s))
{
...
}
In that case code like
MyClass obj((myBigObject()));
will end up with zero copyings as object will be first moved to constructor and then to class field.
Suppose we have this class:
class X {
public:
explicit X (char* c) { cout<<"ctor"<<endl; init(c); };
X (X& lv) { cout<<"copy"<<endl; init(lv.c_); };
X (X&& rv) { cout<<"move"<<endl; c_ = rv.c_; rv.c_ = nullptr; };
const char* c() { return c_; };
private:
void init(char *c) { c_ = new char[strlen(c)+1]; strcpy(c_, c); };
char* c_;
};
and this sample usage:
X x("test");
cout << x.c() << endl;
X y(x);
cout << y.c() << endl;
X z( X("test") );
cout << z.c() << endl;
The output is:
ctor
test
copy
test
ctor <-- why not move?
test
I am using VS2010 with default settings. I'd expect the last object (z) to be move-constructed, but it's not! If I use X z( move(X("test")) ); then the last lines of the output are ctor move test, as I'd expect. Is it a case of (N)RVO?
Q: Should the move-ctor be called according to the standard? If so, why isn't it called?
What you are seeing is copy elision, which allows the compiler to directly construct a temporary into a target it is to be copied/moved into and thus elide a copy (or move) constructor/destructor pair. The situations in which the compiler is allowed to apply copy elision are specified in §12.8.32 of the C++11 standard:
When certain criteria are met, an implementation is allowed to omit
the copy/move construction of a class object, even if the copy/move
constructor and/or destructor for the object have side effects. In such
cases, the implementation treats the source and target of the omitted
copy/move operation as simply two different ways of referring to the
same object, and the destruction of that object occurs at the later of
the times when the two objects would have been destroyed without the
optimization. This elision of copy/move
operations, called copy elision, is permitted in the following
circumstances (which maybe combined to eliminate multiple copies):
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-unqualified type as the function return type, the
copy/move operation can be omitted by constructing the automatic
object directly into the function’s return value
in a throw-expression, when the operand is the name of a non-volatile automatic object whose scope does not extend beyond
the end of the innermost enclosing try-block (if there is one), the
copy/move operation from the operand to the exception object (15.1)
can be omitted by constructing the automatic object directly into
the exception object
when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with he
same cv-unqualified type, the copy/move operation can be omitted by
constructing the temporary object directly into the target of the
omitted copy/move
when the exception-declaration of an exception handler (Clause 15) declares an object of the same type (except for cv-qualification) as
the exception object (15.1), the copy/move operation can be omitted
bytreatingthe exception-declaration as an alias for the exception
object if the meaning of the program will be unchanged except for the
execution of constructors and destructors for the object declared by
the exception-declaration.
The ctor output you get in your third code line is for the construction of the temporary object. After that, indeed, the temporary is moved into the new variable z. In such a situation the compiler may choose to elide the copy/move, and it seems that is what it did.
The Standard states:
(§12.8/31) When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object, even if the copy/move constructor and/or destructor for the object have side effects. [...] This elision of copy/move operations, called copy elision, is permitted in the following circumstances (which may be combined to eliminate multiple copies):
[...]
- when a temporary class object that has not been bound to a reference (12.2) would be copied/moved to a class object with the same cv-unqualified type, the copy/move operation can be omitted by constructing the temporary object directly into the target of the omitted copy/move
[...]
One important condition is that the source object and the destination are of the same type (apart from cv-qualification, i.e. things like const).
Therefore, one way you can force the move constructor to be called is to combine the object initialization with implicit type conversion:
#include <iostream>
struct B
{};
struct A
{
A() {}
A(A&& a) {
std::cout << "move" << std::endl;
}
A(B&& b) {
std::cout << "move from B" << std::endl;
}
};
int main()
{
A a1 = A(); // move elided
A a2 = B(); // move not elided because of type conversion
return 0;
}
You are calling X's char* constructor X("test") explicitly.
Therefore it is printing ctor