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?
If a function returns a std::unique_ptr<> , that means the caller takes ownership of the returned object.
Because the unique pointer does not have a copy constructor. Hence you cannot pass it by value, because passing by value requires making a copy.
A unique_ptr does not share its pointer. It cannot be copied to another unique_ptr , passed by value to a function, or used in any C++ Standard Library algorithm that requires copies to be made. A unique_ptr can only be moved.
class A {} std::unique_ptr<A> f() { return std::make_unique<A>(); } std::unique_ptr<A> a = f(); Hmm, if I remember correctly, a function in C++ returns a copy of the returned object. A function f returns a copy of std::unique_ptr constructed by std::make_unique . How is it possible?
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With