unique_ptr<T> does not allow copy construction, instead it supports move semantics. Yet, I can return a unique_ptr<T> from a function and assign the returned value to a variable.
#include <iostream>
#include <memory>
using namespace std;
unique_ptr<int> foo()
{
unique_ptr<int> p( new int(10) );
return p; // 1
//return move( p ); // 2
}
int main()
{
unique_ptr<int> p = foo();
cout << *p << endl;
return 0;
}
The code above compiles and works as intended. So how is it that line 1 doesn't invoke the copy constructor and result in compiler errors? If I had to use line 2 instead it'd make sense (using line 2 works as well, but we're not required to do so).
I know C++0x allows this exception to unique_ptr since the return value is a temporary object that will be destroyed as soon as the function exits, thus guaranteeing the uniqueness of the returned pointer. I'm curious about how this is implemented, is it special cased in the compiler or is there some other clause in the language specification that this exploits?
is there some other clause in the language specification that this exploits?
Yes, see 12.8 §34 and §35:
When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object [...]
This elision of copy/move operations, called copy elision, is permitted [...]
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 [...]
When the criteria for elision of a copy operation are met 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.
Just wanted to add one more point that returning by value should be the default choice here because a named value in the return statement in the worst case, i.e. without elisions in C++11, C++14 and C++17 is treated as an rvalue. So for example the following function compiles with the -fno-elide-constructors flag
std::unique_ptr<int> get_unique() {
auto ptr = std::unique_ptr<int>{new int{2}}; // <- 1
return ptr; // <- 2, moved into the to be returned unique_ptr
}
...
auto int_uptr = get_unique(); // <- 3
With the flag set on compilation there are two moves (1 and 2) happening in this function and then one move later on (3).
This is in no way specific to std::unique_ptr, but applies to any class that is movable. It's guaranteed by the language rules since you are returning by value. The compiler tries to elide copies, invokes a move constructor if it can't remove copies, calls a copy constructor if it can't move, and fails to compile if it can't copy.
If you had a function that accepts std::unique_ptr as an argument you wouldn't be able to pass p to it. You would have to explicitly invoke move constructor, but in this case you shouldn't use variable p after the call to bar().
void bar(std::unique_ptr<int> p)
{
// ...
}
int main()
{
unique_ptr<int> p = foo();
bar(p); // error, can't implicitly invoke move constructor on lvalue
bar(std::move(p)); // OK but don't use p afterwards
return 0;
}
unique_ptr doesn't have the traditional copy constructor. Instead it has a "move constructor" that uses rvalue references:
unique_ptr::unique_ptr(unique_ptr && src);
An rvalue reference (the double ampersand) will only bind to an rvalue. That's why you get an error when you try to pass an lvalue unique_ptr to a function. On the other hand, a value that is returned from a function is treated as an rvalue, so the move constructor is called automatically.
By the way, this will work correctly:
bar(unique_ptr<int>(new int(44));
The temporary unique_ptr here is an rvalue.
I think it's perfectly explained in item 25 of Scott Meyers' Effective Modern C++. Here's an excerpt:
The part of the Standard blessing the RVO goes on to say that if the conditions for the RVO are met, but compilers choose not to perform copy elision, the object being returned must be treated as an rvalue. In effect, the Standard requires that when the RVO is permitted, either copy elision takes place or std::move is implicitly applied to local objects being returned.
Here, RVO refers to return value optimization, and if the conditions for the RVO are met means returning the local object declared inside the function that you would expect to do the RVO, which is also nicely explained in item 25 of his book by referring to the standard (here the local object includes the temporary objects created by the return statement). The biggest take away from the excerpt is either copy elision takes place or std::move is implicitly applied to local objects being returned. Scott mentions in item 25 that std::move is implicitly applied when the compiler choose not to elide the copy and the programmer should not explicitly do so.
In your case, the code is clearly a candidate for RVO as it returns the local object p and the type of p is the same as the return type, which results in copy elision. And if the compiler chooses not to elide the copy, for whatever reason, std::move would've kicked in to line 1.
One thing that i didn't see in other answers is To clarify another answers that there is a difference between returning std::unique_ptr that has been created within a function, and one that has been given to that function.
The example could be like this:
class Test
{int i;};
std::unique_ptr<Test> foo1()
{
std::unique_ptr<Test> res(new Test);
return res;
}
std::unique_ptr<Test> foo2(std::unique_ptr<Test>&& t)
{
// return t; // this will produce an error!
return std::move(t);
}
//...
auto test1=foo1();
auto test2=foo2(std::unique_ptr<Test>(new Test));
I would like to mention one case where you must use std::move() otherwise it will give an error.
Case: If the return type of the function differs from the type of the local variable.
class Base { ... };
class Derived : public Base { ... };
...
std::unique_ptr<Base> Foo() {
std::unique_ptr<Derived> derived(new Derived());
return std::move(derived); //std::move() must
}
Reference: https://www.chromium.org/developers/smart-pointer-guidelines
I know it's an old question, but I think an important and clear reference is missing here.
From https://en.cppreference.com/w/cpp/language/copy_elision :
(Since C++11) In a return statement or a throw-expression, if the compiler cannot perform copy elision but the conditions for copy elision are met or would be met, except that the source is a function parameter, the compiler will attempt to use the move constructor even if the object is designated by an lvalue; see return statement for details.
Related
I've read several posts about temporary object's lifetime. And in a word I learn that:
the temporary is destroyed after the end of the full-expression
containing
it.
But this code is out of my expectation:
#include <memory>
#include <iostream>
void fun(std::shared_ptr<int> sp)
{
std::cout << "fun: sp.use_count() == " << sp.use_count() << '\n';
//I expect to get 2 not 1
}
int main()
{
fun(std::make_shared<int>(5));
}
So I think I have 2 smart pointer objects here, one is std::make_shared<int>(5), the temporary unnamed object and the other sp which is a local variable inside the function. So based on my understanding, the temporary one won't "die" before completing the function call. I expect output to be 2 not 1. What's wrong here?
Pre-C++17, sp is move-constructed from the temporary if the move is not elided to begin with. In either case, sp is the sole owner of the resource, so the use count is rightly reported as 1. This is overload 10)† in this reference.
While the temporary still exists, if not elided, it is in a moved-from state and no longer holds any resource, so it doesn't contribute to the resource's use count.
Since C++17, no temporary is created thanks to guaranteed copy/move elision, and sp is constructed in place.
† Exact wording from said reference:
10) Move-constructs a shared_ptr from r. After the construction, *this contains a copy of the previous state of r, r is empty and its stored pointer is null. [...]
In our case, r refers to the temporary and *this to sp.
c++ has a strange concept known as elision.
Elision is a process whereby the compiler is allowed to take the lifetime of two objects and merge them. Typically people say that the copy or move constructor "is elided", but what is really elided is the identity of two seemingly distinct objects.
As a rule of thumb, when an anonymous temporary object is used to directly construct another object, their lifetimes can be elided together. So:
A a = A{}; // A{} is elided with a
void f(A);
f(A{}); // temporary A{} is elided with argument of f
A g();
f(g()); // return value of g is elided with argument of f
There are also situations where named variables can be elided with return values, and more than two objects can be elided together:
A g() {
A a;
return a; // a is elided with return value of g
}
A f() {
A x = g(); // x is elided with return value of g
// which is elided with a within g
return x; // and is then elided with return value of f
}
A bob = f(); // and then elided with bob.
Only one instance of A exists in the above code; it just has many names.
In c++17 things go even further. Prior to that the objects in question had to logically be copyable/movable, and elision simply eliminated calls the the constructor and shared the objects identity.
After c++17 some things that used to be elision are (in some sense) "guaranteed elision", which is really a different thing. "Guaranteed elision" is basically the idea that prvalues (things that used to be temporaries in pre-c++17) are now abstract instructions on how to create an object.
In certain circumstances temporaries are instantiated from them, but in others they are just used to construct some other object in some other spot.
So in c++17 you should think of this function:
A f();
as a function that returns instructions on how to create a A. When you do this:
A a = f();
you are saying "use the instructions that f returns to construct an A named a".
Similarly, A{} is no longer a temporary but instructions no how to create an A. If you put it on a line by itself those instructions are used to create a temporary, but in most contexts no temporary logically or actually exists.
template<class T, class...Us>
std::shared_ptr<T> make_shared(Us&&...);
this is a function that returns instructions on how to create a shared_ptr<T>.
fun(std::make_shared<int>(5));
here you apply these instructions to the agument of fun, which is of type std::shared_ptr<int>.
In pre-[C++17] without hostile compiler flags, the result with elision is practically the same here. In that case, the temporaries identity is merged with the argument of fun.
In no practical case will there be a temporary shared_ptr with a reference count of 0; other answers which claim this are wrong. The one way where that can occur is if you pass in flags that your compiler from performing elision (the above hostile compiler flags).
If you do pass in such flags, the shared_ptr is moved-from into the argument of fun, and it exists with a reference count of 0. So use_count will remain 0.
In addition to the move construction of std::shared_ptr, there is another aspect to consider: in-place creation of function argument passed by value. This is an optimization that compilers usually do. Consider the exemplary type
struct A {
A() { std::cout << "ctor\n"; }
A(const A&) { std::cout << "copy ctor\n"; }
};
together with a function that takes an instance of A by value
void f(A) {}
When the function parameter is passed as an rvalue like this
f(A{});
the copy constructor won't be called unless you explicitly compile with -fno-elide-constructors. In C++17, you can even delete the copy constructor
A(const A&) = delete;
because the copy elision is guaranteed. With this in mind: the temporary object that you pass as a function argument is "destroyed after the end of the full-expression containing it" only if there is a temporary, and a code snippet might suggest the existence of one even though it's easily (and since C++17: guaranteed to be) optimized out.
suppose I have the following code.
std::string foo() {
std::string mystr("SOMELONGVALUE");
return mystr;
}
int main() {
std::string result = foo();
}
When I call 'foo', is the data in mystr copied or moved into result? I believe that it is moved C++11 style, but I was hoping for clarification and/or links to show that.
Thanks!
Edit: I suppose I want to know the answer to this question when compiling with g++ for c++11 or later.
Your example fall on the so-called Named Return Value Optimization, which is defined in this paragraph of the C++11 standard. So the compiler may elide the copy constructor (or move constructor since C++14). This elision is not mandatory.
In C++11, if the compiler does not perform this elision, the returned string will be copy constructed. The returned object would be moved if it were naming a function parameter, [class.copy]/32 (bold is mine):
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. [...]
In C++14, this last rule has changed. It also includes the case of automatic variables [class.copy]/32:
When the criteria for elision of a copy/move operation are met, but not for an exception-declaration, and the object to be copied is designated by an lvalue, or when 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. [...]
So in your example code, and in C++14, if the compiler does not elide the copy/move construction, the returned string will be move constructed.
Like user4581301 said, I suspect copy elision to happen (not a move) in most implementations. For c++11 and c++14, the standard allows copy elision to happen but doesn't mandate it. In c++17, some instances of copy elision will become mandated. So, for c++11 and c++14, technically the answer depends on the implementation being used. In your case specifically, we're talking about a specific type of copy elision: return value optimization (RVO). To check whether RVO happens in your environment for your given case, you can run this code:
#include <iostream>
struct Foo {
Foo() { std::cout << "Constructed" << std::endl; }
Foo(const Foo &) { std::cout << "Copy-constructed" << std::endl; }
Foo(Foo &&) { std::cout << "Move-constructed" << std::endl; }
~Foo() { std::cout << "Destructed" << std::endl; }
};
Foo foo() {
Foo mystr();
return mystr;
}
int main() {
Foo result = foo();
}
My implementation opts for RVO - no move takes place.
Since std::string result = foo(); is an initializer, it will call the constructor rather than the assignment operator. In C++11 or newer, there is guaranteed to be a move constructor with prototype std::basic_string::basic_string( basic_string&& other ) noexcept. On every actually-existing implementation, this moves the contents rather than copying them. Although I don’t believe the standard mandates a particular implementation, it does say this particular operation must run in constant and not linear time, which precludes a deep copy. As the return value of foo() is a temporary rvalue, that is the constructor that will be called in this snippet.
So, yes, this code will move the string rather than copy it.
The expression in a return statement will not always be copied, however. If you return std::string("SOMELONGVALUE"); (a programmatic constructor), the implementation is permitted to construct the result in place instead. If foo() returns a std::string& and returns anything other than a temporary, that will be returned by reference. (Returning a reference to a temporary that's been destroyed is, as you know, undefined behavior!) And some compilers, even before C++11, would perform copy elision and avoid creating a temporary only to copy and destroy it. Newer versions of the Standard make copy elision mandatory in most situations where it’s possible, but compilers were doing it even before that.
The way the most compilers implement return of a class type is to pass an extra "hidden" argument to the function that is a pointer to the memory where the value being returned should be constructed. So the called function can copy or move the return value into that memory as needed without regard to the call site.
With your example code, such a compiler could even use that same memory to hold the mystr variable, constructing it directly there, and never using either the move or copy constructor of std::string.
In my VS2015, the compiler does invoke move ctor when returning an temp variable in such a trivial case.
class A {
public:
A(int _x) :x(_x) {}
A(const A& a) {
cout << "copy ctor." << endl;
x = a.x;
}
A(A&& a) {
cout << "move ctor." << endl;
x = 123;
}
private:
int x;
};
A foo() {
A temp = { 7 };
return temp; //invoke move ctor
}
int main() {
A a = foo();
return 0;
}
Besieds, whether the compiler trigger RVO depends on the
price of copying, you can see the mechanism of RVO in below:
https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/RVO_V_S_std_move?lang=en
unique_ptr<T> does not allow copy construction, instead it supports move semantics. Yet, I can return a unique_ptr<T> from a function and assign the returned value to a variable.
#include <iostream>
#include <memory>
using namespace std;
unique_ptr<int> foo()
{
unique_ptr<int> p( new int(10) );
return p; // 1
//return move( p ); // 2
}
int main()
{
unique_ptr<int> p = foo();
cout << *p << endl;
return 0;
}
The code above compiles and works as intended. So how is it that line 1 doesn't invoke the copy constructor and result in compiler errors? If I had to use line 2 instead it'd make sense (using line 2 works as well, but we're not required to do so).
I know C++0x allows this exception to unique_ptr since the return value is a temporary object that will be destroyed as soon as the function exits, thus guaranteeing the uniqueness of the returned pointer. I'm curious about how this is implemented, is it special cased in the compiler or is there some other clause in the language specification that this exploits?
is there some other clause in the language specification that this exploits?
Yes, see 12.8 §34 and §35:
When certain criteria are met, an implementation is allowed to omit the copy/move construction of a class object [...]
This elision of copy/move operations, called copy elision, is permitted [...]
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 [...]
When the criteria for elision of a copy operation are met 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.
Just wanted to add one more point that returning by value should be the default choice here because a named value in the return statement in the worst case, i.e. without elisions in C++11, C++14 and C++17 is treated as an rvalue. So for example the following function compiles with the -fno-elide-constructors flag
std::unique_ptr<int> get_unique() {
auto ptr = std::unique_ptr<int>{new int{2}}; // <- 1
return ptr; // <- 2, moved into the to be returned unique_ptr
}
...
auto int_uptr = get_unique(); // <- 3
With the flag set on compilation there are two moves (1 and 2) happening in this function and then one move later on (3).
This is in no way specific to std::unique_ptr, but applies to any class that is movable. It's guaranteed by the language rules since you are returning by value. The compiler tries to elide copies, invokes a move constructor if it can't remove copies, calls a copy constructor if it can't move, and fails to compile if it can't copy.
If you had a function that accepts std::unique_ptr as an argument you wouldn't be able to pass p to it. You would have to explicitly invoke move constructor, but in this case you shouldn't use variable p after the call to bar().
void bar(std::unique_ptr<int> p)
{
// ...
}
int main()
{
unique_ptr<int> p = foo();
bar(p); // error, can't implicitly invoke move constructor on lvalue
bar(std::move(p)); // OK but don't use p afterwards
return 0;
}
unique_ptr doesn't have the traditional copy constructor. Instead it has a "move constructor" that uses rvalue references:
unique_ptr::unique_ptr(unique_ptr && src);
An rvalue reference (the double ampersand) will only bind to an rvalue. That's why you get an error when you try to pass an lvalue unique_ptr to a function. On the other hand, a value that is returned from a function is treated as an rvalue, so the move constructor is called automatically.
By the way, this will work correctly:
bar(unique_ptr<int>(new int(44));
The temporary unique_ptr here is an rvalue.
I think it's perfectly explained in item 25 of Scott Meyers' Effective Modern C++. Here's an excerpt:
The part of the Standard blessing the RVO goes on to say that if the conditions for the RVO are met, but compilers choose not to perform copy elision, the object being returned must be treated as an rvalue. In effect, the Standard requires that when the RVO is permitted, either copy elision takes place or std::move is implicitly applied to local objects being returned.
Here, RVO refers to return value optimization, and if the conditions for the RVO are met means returning the local object declared inside the function that you would expect to do the RVO, which is also nicely explained in item 25 of his book by referring to the standard (here the local object includes the temporary objects created by the return statement). The biggest take away from the excerpt is either copy elision takes place or std::move is implicitly applied to local objects being returned. Scott mentions in item 25 that std::move is implicitly applied when the compiler choose not to elide the copy and the programmer should not explicitly do so.
In your case, the code is clearly a candidate for RVO as it returns the local object p and the type of p is the same as the return type, which results in copy elision. And if the compiler chooses not to elide the copy, for whatever reason, std::move would've kicked in to line 1.
One thing that i didn't see in other answers is To clarify another answers that there is a difference between returning std::unique_ptr that has been created within a function, and one that has been given to that function.
The example could be like this:
class Test
{int i;};
std::unique_ptr<Test> foo1()
{
std::unique_ptr<Test> res(new Test);
return res;
}
std::unique_ptr<Test> foo2(std::unique_ptr<Test>&& t)
{
// return t; // this will produce an error!
return std::move(t);
}
//...
auto test1=foo1();
auto test2=foo2(std::unique_ptr<Test>(new Test));
I would like to mention one case where you must use std::move() otherwise it will give an error.
Case: If the return type of the function differs from the type of the local variable.
class Base { ... };
class Derived : public Base { ... };
...
std::unique_ptr<Base> Foo() {
std::unique_ptr<Derived> derived(new Derived());
return std::move(derived); //std::move() must
}
Reference: https://www.chromium.org/developers/smart-pointer-guidelines
I know it's an old question, but I think an important and clear reference is missing here.
From https://en.cppreference.com/w/cpp/language/copy_elision :
(Since C++11) In a return statement or a throw-expression, if the compiler cannot perform copy elision but the conditions for copy elision are met or would be met, except that the source is a function parameter, the compiler will attempt to use the move constructor even if the object is designated by an lvalue; see return statement for details.
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 the code below, what it is used to avoid copy, elision or rvalue reference and move constructor ?
std::string get(){return "...";}
void foo(std::string var){}
foo( get() ); //<--- here
std::string get(){
// this is similar to return std::string("..."), which is
// copied/moved into the return value object.
return "...";
}
RVO allows it to construct the temporary string object directly into the return value object of get().
foo( get() );
RVO allows it to directly construct the temporary string object (the return value object) directly into the parameter object of foo.
These are the RVO scenarios allowed. If your compiler cannot apply them, it has to use move constructors (if available) to move the return value into the return value object and the parameter object, respectively. In this case that is not surprising because both temporary objects are or are treated as rvalues anyway. (For the first scenario, no expression corresponds to the created temporary, so the treatment is only for the purpose of selecting what constructor is used for copying/moving the temporary into the return value object).
For other cases, the compiler has to consider things as rvalues even if they are otherwise lvalues
std::string get(){
std::string s = "...";
// this is similar to return move(s)
return s;
}
The spec says when it could potentially apply RVO (or NRVO) to an lvalue by the rules it sets forth, the implementation is required to treat the expressions as rvalues and use move constructors if available, and only if it couldn't find a suitable constructor, it should use the expression as an lvalue. It would be a pity for the programmer to write explicit moves in these cases, when it's clear the programmer would always want a move instead of a copy.
Example:
struct A { A(); A(A&); };
struct B { B(); B(B&&); };
A f() { A a; return a; }
B f() { B b; return b; }
For the first, it takes a as an rvalue, but cannot find constructors that accept this rvalue (A& cannot bind to rvalues). Therefor, it then again treats a as what it is (an lvalue). For the second, it takes b as a rvalue, and has B(B&&) take that rvalue and move it. If it would have taken b as an lvalue (what it is), then the copy initialization would have failed, because B has no copy constructor implicitly declared.
Note that returning and paramter passing uses the rules of copy initialization, which means
u -> T (where u's type is different from T) =>
T rvalue_tmp = u;
T target(rvalue_tmp);
t -> T (where t's type is T) =>
T target = t;
Hence, in the example where we return a "...", we first create an rvalue temporary and then move that into the target. For the case where we return an expression of the type of the return value / paramter, we will directly move / copy the expression into the target.
Most likely copy ellision, but if your compiler cannot apply in this case, which can happen if the functions are more complex, then you're looking at a move. Moves are extremely efficient, so I wouldn't panic here if ellision is not performed.
Implementation defined, but most likely copy elision.
Similarly, RVO/NRVO will most likely kick in before move semantics when returning an object value from a function.