Given
struct Range{
Range(double from, double to) : from(from), to(to) {}
double from;
double to;
// if it matters to the compiler, we can add more fields here to make copying expensive
};
struct Box{
Box(Range x, Range y) : x(x), y(y) {}
Range x;
Range y;
};
someone said that in Box box(Range(0.0,1.0),Range(0.0,2.0)), the compiler can avoid copying Range objects altogether by constructing them inside box to begin with.
Does any compiler actually do this?
My own attempts haven't succeeded.
The compiler can - and normally does - elide the copies from the temporary to the argument. The compiler cannot elide the copy from the argument to members. While it may technically possible to elide these copies in some cases, the relevant permission isn't given. The section of the standard is 12.8 [class.copy] paragraph 31 which spells out 4 situations where a copy can be elided (the exact rules are a bit non-trivial):
When returning a named, function local variable using it name.
When using a named, function local variable in a throw expression.
When copying a temporary object.
When catching an exception by value.
Passing a named argument as parameter to the construction of a member variable is, clearly, none of these situations.
The essential background of the rules for copy elision is that in some contexts the declaration of functions suffice to determine when an object will be used. If it is clear upon construction time where the object can be constructed, it can be elided. The caller of a constructor cannot determine based only on the declaration of the constructor where the object will be used.
That Someone is me. So let me clear my stand.
I never said that in Box box(Range(0.0,1.0),Range(0.0,2.0)), the compiler can avoid copying Range objects altogether by constructing them inside box to begin with. What I said was:
Yes it can, In particular this kind of copy elision context falls under the copy elision criterion specified in 12.8/p31.3 Copying and moving class objects [class.copy] of the standard:
(31.3) -- 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 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.
The Yes it can, part goes for the temporary objects passed in the constructor (That can be elide per standard as mentioned above). I never said that the parameters can be elided all the way to the Box constructor's initializer list.
After all, that case doesn't qualify for any of the criteria where copy elision can be applied as per standard.
I also said that even if a certain context is qualified as a context where copy elision can be applied, the compiler is not obligated to follow. If you rely on that effects then your program is not considered portable.
Related
C++17 guarantees copy elision for:
T funcReturningT() {
return T(...);
}
T t=funcReturningT();
Now if I wrap the return into a static_cast to the same type, like so:
T t=static_cast<T>(funcReturningT());
does the standard still guarantee copy elision or not?
RVO is dead. Long live RVO.
In modern C++, there are two cases corresponding to what used to be called RVO:
There's NRVO, in which the compiler is allowed to elide a local variable if it can see that that variable will just be returned eventually. If the compiler declines to elide the local variable, then it is obligated to treat it as an rvalue when it is returned, assuming certain conditions are met (thus converting a copy into a move). This is not what your question is asking about.
There's also guaranteed copy elision --- but to even use that name for it is to think about C++17 using a pre-C++17 mindset. What really changed in C++17 is that prvalues are no longer "objects without identity" but rather "recipes for creating objects". This is the reason why copy-elision-like behaviour is guaranteed.
So let's look at your statement:
T t=static_cast<T>(funcReturningT());
The expression funcReturningT() is a prvalue. In C++14, this would mean that immediately upon evaluating it, the implementation would have to instantiate a temporary T object (lacking identity), but non-guaranteed copy elision would allow the compiler (at its discretion) to elide such object. In C++17, it is ready to create a T object but doesn't do so immediately.
Then the static_cast is evaluated, and the result of it is also a prvalue of the same type. Because of this, no move constructor is required and no temporary object needs to be created. The result of the cast is just the original "recipe".
And finally, when t is initialized from the result of the static_cast, the move constructor is once again not required. The "recipe" that static_cast used is simply executed with t as the object that it creates.
The beauty of it is that there is nothing to elide, which is why "guaranteed copy elision" is a misnomer.
(Sometimes, temporary objects do need to be created: in particular, if any constructor or conversion function needs to be called at any point, then the prvalue has to be "materialized" in order for that call to actually have an object to work with. In your example, this is not necessary.)
From the standard 6.7.7 (temporary objects), we can see:
When an object of class type X is passed to or returned from a function, if X has at least one eligible copy or move constructor ([special]), each such constructor is trivial, and the destructor of X is either trivial or deleted, implementations are permitted to create a temporary object to hold the function parameter or result object. The temporary object is constructed from the function argument or return value, respectively, and the function's parameter or return object is initialized as if by using the eligible trivial constructor to copy the temporary (even if that constructor is inaccessible or would not be selected by overload resolution to perform a copy or move of the object).
[Note 4: This latitude is granted to allow objects of class type to be passed to or returned from functions in registers. — end note]
Does it mean that copy elision is not mandatory with trivially copyable types? What I understand here is that if we declare a destructor like ~Object() {} instead of not declaring anything (so the destructor would be generated by the compiler) or a default one, the object becomes not trivially constructible, and so, the copy elision must be performed (at the condition we respect the well-known condition for copy elision to occur).
Does it mean that copy elision is not mandatory with trivially copyable types?
In principle, yes, but the goal of the section you quoted was not to exempt POD types from copy elision but to bypass ABI restrictions on how objects are passed in function calls. It allows POD objects to be passed via registers. This is the best the standard can do given the C++ abstract machine knows nothing about the physical machine and its registers and calling conventions.
Guaranteed copy elision is a result of several changes spread throughout the standard, which includes deferred prvalue materialization. For details refer to the original proposal p0135r1.
With those changes it becomes possible (and required) to initialize an object without involving temporaries ([dcl.init.general]/15.6.1):
— Otherwise, if the destination type is a (possibly
cv-qualified) class type:
If the initializer expression is a prvalue and the cv-unqualified version of the source type is the same class as the
class of the destination, the initializer expression is used to
initialize the destination object.
Why does this program call the copy constructor instead of the move constructor?
class Qwe {
public:
int x=0;
Qwe(int x) : x(x){}
Qwe(const Qwe& q) {
cout<<"copy ctor\n";
}
Qwe(Qwe&& q) {
cout<<"move ctor\n";
}
};
Qwe foo(int x) {
Qwe q=42;
Qwe e=32;
cout<<"return!!!\n";
return q.x > x ? q : e;
}
int main(void)
{
Qwe r = foo(50);
}
The result is:
return!!!
copy ctor
return q.x > x ? q : e; is used to disable nrvo. When I wrap it in std::move, it is indeed moved. But in "A Tour of C++" the author said that the move c'tor must be called when it available.
What have I done wrong?
You did not write your function in a way that allows copy/move elision to occur. The requirements for a copy to be replaced by a move are as follows:
[class.copy.elision]/3:
In the following copy-initialization contexts, a move operation might
be used instead of a copy operation:
If the expression in a return statement is a (possibly parenthesized) id-expression that names an object with automatic
storage duration declared in the body or
parameter-declaration-clause of the innermost enclosing function or lambda-expression
overload resolution to select the constructor for the copy is first
performed as if the object were designated by an rvalue. If the first
overload resolution fails or was not performed, 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.
The above is from C++17, but the C++11 wording is pretty much the same. The conditional operator is not an id-expression that names an object in the scope of the function.
An id-expression would be something like q or e in your particular case. You need to name an object in that scope. A conditional expression doesn't qualify as naming an object, so it must preform a copy.
If you want to exercise your English comprehension abilities on a difficult wall of text, then this is how it's written in C++11. Takes some effort to see IMO, but it's the same as the clarified version above:
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):
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
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
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.
StoryTeller didn't answer the question: Why is the move c'tor not called? (And not: Why is there no copy elision?)
Here's my go: The move c'tor will be called if and only if:
Copy elision (RVO) is not performed. Your use of the ternary operator is indeed a way to prevent copy elision. Let me point out though that return (0, q); is a simpler way to do this if you just want to return q while suppressing copy elision. This uses the (in-)famous comma operator. Possibly return ((q)); might work, too, but I am not enough of a language lawyer to tell for sure.
The argument to return is an rvalue. This could be a temporary (more precisely, a prvalue), but these are also eligible for copy elision. Therefore, the argument to return must be an xvalue, such as std::move(q) if you want to ensure the move c'tor is called.
See also: C++ value categories
Some more technicalities of your example:
q and e are objects of type Qwe.
q.x > x ? q : e is an lvalue expression of type Qwe. This is because the expressions q and e are lvalues of type Qwe. The ternary operator just selects either of them.
std::move(q.x > x ? q : e) is an xvalue expression of type Qwe. The std::move simply turns (casts) the lvalue into an xvalue. As an aside, q.x > x ? std::move(q) : std::move(e) would also work.
The copy c'tor gets called in return q.x > x ? q : e; because it can be called with an lvalue of type Qwe (constness is optional), while, on the other hand, the move c'tor cannot be called with an lvalue and is therefore eliminated from the candidate set.
UPDATE: Addressing the comments by going into more depth… this is a really confusing aspect of C++!
Conceptually, in C++98, returning an object by value meant returning a copy of the object, so the copy c'tor would be called. However, the standard's authors considered that a compiler should be free to perform an optimization such that this potentially expensive copy (e.g. of a container) could be elided under suitable circumstances.
This copy elision means that, instead of creating the object in one place and then copying it to a memory address controlled by the caller, the callee creates the object directly in the memory controlled by the caller. Therefore, only the "normal" constructor, e.g. a default c'tor, is called.
Therefore, they added a passage such that the compiler is required to check that the copy c'tor — whether generated or user-defined – exists and is accessible (there was no notion yet of deleted functions for that matter), and must ensure that the object is initialized as-if it had been first created in a different place and then copied (cf. as-if rule), but the compiler was not required to ensure that any side effects of the copy c'tor would be observable, such as the stream output in your example.
The reason why the c'tor was still required to be there was that they wanted to avoid a scenario where a compiler was able to accept code that another would have to reject, simply because the former implemented an optional optimization that the latter did not.
In C++11, move semantics were added, and the committee very much wanted to use this in such a manner that a lot of existing return-by-value functions e.g. involving strings or containers would become more efficient. This was done in such a way that conditions were given under which the compiler was actually required to perform a move instead of a copy. However, the idea of copy elision remained important, so basically there were now four different categories:
The compiler is required to check for a usable (see above) move c'tor, but is allowed to elide it.
The compiler is required to check for a usable move c'tor, and has to call it.
The compiler is required to check for a usable copy c'tor, but is allowed to elide it.
The compiler is required to check for a usable copy c'tor, and has to call it.
… which in turn lead to four possible outcomes:
Compiler checks for move c'tor, but then elides it. (relates to 1. above)
Compiler checks for move c'tor and actually emits a call to it. (relates to 1. or 2. above)
Compiler checks for copy c'tor, but then elides it. (relates to 3. above)
Compiler checks for copy c'tor and actually emits a call to it. (relates to 3. or 4. above)
And the long optimization story doesn't end here, because, in C++17, the compiler is required to elide certain c'tor calls. In these cases, the compiler is not even allowed to demand that a copy or move c'tor is available.
Note that a compiler has always been free to elide even such c'tor calls that do not meet the standard requirements, under the protection of the as-if rule, for instance by function inlining and the following optimization steps. Anyway, a function call, conceptually, does not have to be backed by the actual machine instruction for the execution of a subroutine. The compiler is just not allowed to remove observable, otherwise defined behavior.
By now you should have noticed that, at least prior to C++17, it is very well possible for the same well-formed program to behave differently, depending on the compiler used and even optimization settings, if the copy rsp. move constructor has observable side effects. Also, a compiler that implements copy/move elision may do so for a subset of the conditions under which the standard allows it to happen. This makes your question almost impossible to answer in detail. Why is the copy/move c'tor called here, but not there? Well, it may be because of the requirements of the C++ standard, but it also may be the preference of your compiler. Maybe the compiler authors had time and leisure implementing the one optimization but not the other. Maybe they found it too difficult in the latter case. Maybe they just had more important stuff to do. Who knows?
What matters 99% of the time for me as a developer is to write my code in such a way that the compiler can apply the best optimizations. Sticking to common cases and standard practice is one thing. Knowing NRVO and RVO of temporaries is another thing, and writing the code such that the standard allows (or, in C++17, requires) copy/move elision, and ensuring that a move c'tor is available where it is beneficial (in case elision does not occur). Don't rely on side effects such as writing a log message or incrementing a global counter. These are not what a copy or move c'tor should commonly do anyway, except possibly for debugging or scholarly interest.
This question already has answers here:
How does guaranteed copy elision work?
(2 answers)
What are copy elision and return value optimization?
(5 answers)
Closed 5 years ago.
I learned, long ago, that copy initialization creates a temporary which is then used to initialize the destination, though the latter copy constructor is optimized out; but the compiler still pretends to use it, checking for existence and allowed access.
I noticed Herb Sutter mention, in updated GOTW posts, that this is no longer true when auto is used.
Specifically, Herb (writing in 2013) still states the familiar rules in general:
If x is of some other type, conceptually the compiler first implicitly converts x to a temporary widget object… Note that I said “conceptually” a few times above. That’s because practically compilers are allowed to, and routinely do, optimize away the temporary — from GOTW #1
He later notes that when auto is used (in auto w = x;) that only a single copy constructor is called because there is no way that x needs to be converted first.
In the case of a function returning an iterator (so it’s an rvalue):
After all, as we saw in GotW #1, usually that extra = means the two-step “convert to a temporary then copy/move” of copy-initialization—but recall that doesn’t apply when using auto like this. … presto! there cannot be any need for a conversion and we directly construct i. —GOTW #2 (emphasis mine)
If the type returned from the function was exactly the same type as the variable being initialized with copy initialization, the rule would be that the temporary gets optimized out but it still checks access on the copy constructor. Herb is saying that this is not the case with auto, but direct initialization is used.
There are other examples where he seems to be saying (though not with rigorous precision) that when using auto you no longer have the compiler pretend to use the copy constructor.
What’s going on? Has the rule changed? Is this some additional feature of auto that all the presentations have missed mentioning?
I examined the C++17 standard (n4659) and could not find any special mention of auto in the section on initialization, nor anything about initialization in the section on auto. So, I went back to basics and read the rules for initialization in detail. And boy, has it changed! In C++17, the meaning of copy-initialization is not what you learned earlier. The many answers here on SO, and tutorials that explain how the copy constructor is needed but then optimized out are all obsolete, and now wrong.
C++17 has changed the way temporaries are handled, in order to support more copy elision and to enable a way to explain mandatory copy elision. In a nutshell, prvalues are not temporaries that may be optimized away but are still logically copied (or moved) to their final home. Instead, prvalues are sort of in limbo, with no address and no real existence. If a temporary is actually needed, one is “materialized”. But the idea here is that the prvalue can be collapsed out and the code that creates a value (such as the return statement) can be matched up with the final target, avoiding the creation of a temporary.
You can see that this directly affects the meaning of initialization, and by itself cuts out the old rule about a temporary in copy initialization.
So here’s the deal:
the new initialization rules
direct-initialization vs copy-initialization
This description covers the case where an object of class type is being defined. That is, not a reference, not a primitive type, etc. To keep the description simple, I’m not mentioning move constructors every place that copy constructor is mentioned.
C c1 ( exp() ); //exp returns a value, not a reference.
C c2 (v);
C c3 = exp();
C c4 = v;
We have direct initialization (c1 and c2) and copy initialization (c3 and c4). The list forms will be covered separately.
The following cases are covered in order of priority. Each rule is described assuming that earlier rules did not match already.
prvalue
If the source is a prvalue (pure rvalue) and already the right type, we get the match-up between the place that created the value and the final destination. That is, in c1 and c3, the value created by the return statement in exp will be created directly in the variable. In underlying machine language, the caller determines where the return value will go and passes this to exp as another parameter or a dedicated register or whatnot. Here, the address where c1 (or c3) will go is passed for this purpose. It always did that (in optimized code); but logically the caller set up a temporary and then copied the temporary to c3, but was allowed to optimize out the copy. Now, there is no temporary. The direct pipeline from value creation inside the function to the declared variable in the caller is part of the specification.
Note that this new reality affects prvalues in general. A prvalue (pure rvalue) is what you have when a function returns an object by value. The passage that explains this case (§11.6 ¶17.6.1) doesn’t even mention copy vs direct forms!
This means that the copy constructor is not involved. Assuming the function had some way to create the object (a different constructor or private access), you can create a variable when you don’t have an accessible copy constructor at all. This can be handy for factories, where you want to control how objects are created and the type is not copyable and not movable.
direct, and sometimes copy
In direct-initialization (c2), the parameters are used to call a constructor. Being direct, explicit constructors are considered. This should be familiar enough.
In copy-initialization, if the value is the same class as the destination or even a derived class, the value is used as a parameter to a constructor. That is c4 where v is also of class C, or class D derived from C so it is-a C. We suppose that would be the copy constructor that’s chosen, but you can have special constructors for derived types. Being copy-initialization, explicit constructors are ignored. The copy constructor can’t be explicit anyway. But you could have C::C(const D&) that’s explicit!
copy
In remaining cases of copy initialization, some conversion is found. For c4 suppose v is of type E. The conversion functions are conversion operators defined in E (e.g. E::operator C()) and non-explicit constructors in C (e.g. C::C(const E&)). The result of the conversion is then used with direct-initialization. That sounds familiar… but here is the tricky part: the conversion function might produce a prvalue! A normal conversion operator will return by value, so the return value from that operator is constructed directly in c4. It’s possible to write a conversion operator that returns a reference, and is thus an lvalue. But converting constructors are always prvalues. So, it appears that if a constructor is used then copy-initialization is just as direct as direct-initialization. But now it’s a phantom prvalue, not a temporary, that goes away.
list initialization
C c5 { v1,foo(),7 };
C c6 = { v1,foo(),7 };
C c7 = {exp()};
First of all, if C has a special constructor for initialization lists, then that is used. None of the regular stuff applies.
Otherwise, it’s pretty much the same as before. There are a few differences (§11.6.4 ¶3.6):
Because of the new syntax, it’s possible to specify multiple arguments for a constructor in the copy-initialization form. For example, c5 and c6 both specify the same constructor arguments. In copy-initialization the explicit constructors are disallowed. Note that I wrote disallowed not ignored: In regular copy-initialization, explicit constructors are ignored and overload resolution uses only the non-explicit forms. But in copy-list-initialization, all constructors are used for overload resolution, but then if an explicit constructor is chosen you get an error (§16.3.1.7).
Another difference is that when using the list syntax, narrowing conversions (§11.6.4 ¶7) are flagged as errors if they would be used in implicit conversions.
Now for a big surprise: the temporary is back! in case c7, even though exp() is a prvalue, the rule is to match that to constructor arguments. So, the expression produced a value of type C, but then the value is used to pick a constructor (which will be the copy constructor). Since the copy constructor cannot be explicit, there is no difference between the direct and copy syntax.
What does a normal programmer need to know?
This is all rather complex, but a normal day-to-day coder only needs to understand a few simple rules.
prvalues are piped directly to the new home. So the details happened in the function return, and there really isn’t anything happening here. So, there is no meaningful distinction between copy and direct syntax.
copy-initialization vs direct-initialization affects explicit constructors.
direct-initialization specifically asks for a constructor; copy-initialization can use any way of converting.
for lists:
list-initialization can use a special list constructor (e.g. std::vector).
list-initialization gives constructor arguments, but doesn’t allow narrowing conversions.
So, there’s the new part about lists. But really, it’s something you need to unlearn: forget about the convert-then-(pretend to)copy business.
std::string my_func(){
return std::string("...");
}
std::string can be replaced by std::vector or anything else. In general, how do I know rv was moved and not copied?
According to cppreference,
In C++11, expressions that ...
do not have identity and can be moved from are called prvalue ("pure rvalue") expressions.
A temporary object like the one you are returning (std::string("...")) has no identity and can be moved from because the compiler can detect that its state will not be used before its lifetime ends. Thus, the compiler will prefer to move the object over copying it.
However, the temporary object will likely not get moved or copied at all because of return value optimization (RVO), a form of copy elision optimization that constructs the object in the storage that it would otherwise be moved to. So if you were to write std::string str = my_func();, the code would likely be optimized to construct str from "..." in-place, rather than constructing a string inside my_func() and then moving it out. RVO applies for any kind of object that is copyable and/or movable.
A move constructor takes a rvalue reference. A rvalue reference is preferred over a lvalue reference to const when dealing with prvalues. So, as long as your type has a valid move constructor the compiler will chose the move constructor and only fall back to the copy constructor if there isn't move constructor.
That said in this case most likely nothing will be copied or moved and RVO will kick in which directly constructs the object at the call site. The only way to know though if it did is to inspect the assembly.
Starting in C++17 with guaranteed copy elision you are actually guaranteed that no copy or move will happen here.