copy-elision

This question already has an answer here: Returning unique_ptr from functions 5 answers std::unique_ptr<int> ptr() { std::unique_ptr<int> p(new int(3)); return p; // Why doesn't this require explicit move using std::move? } // Why didn't the data pointed to by 'p' is not destroyed here though p is not moved? int main() { std::unique_ptr<int> a = ptr(); // Why doesn't this require std::move? std::cout << *a; // Prints 3. } In the above code, the function ptr() returns a copy of p . When p goes out of scope, the data '3' should get deleted. But how does the code work without any access violation

Some people are not aware that it's possible to pass and return structs by value in C . My question is about the compiler making unnecessary copies when returning structs in C. Do C compilers such as GCC use Return value optimization(RVO) optimization or is this a C++ only concept? Everything I have read about RVO and copy elision is in regards to C++. Let's consider an example. I'm currently implementing a double-double data type in C (or rather float-float to start with because I find it easy to unit test). Consider the following code. typedef struct { float hi; float lo; } doublefloat;

I push_back a temporary object into a vector like this, vector<A> vec; vec.push_back(A("abc")); will the compiler apply copy-elision to construct the temporary A("abc") directly into the vector , so that A 's copy ctor won't be triggered when pushing the temporary object into vec . If you have a compiler that supports rvalue references, it will be moved into the vector, which is sometimes quite cheap. An alternative to that is to directly construct the object in the vector, which can be done with vec.emplace_back("abc"); . This only invokes one constructor. Both of these are C++11 features.

Consider the following: struct X { X() {} X(X&&) { puts("move"); } }; X x = X(); In C++14, the move could be elided despite the fact that the move constructor has side effects thanks to [class.copy]/31, This elision of copy/move operations ... is permitted in the following circumstances ... 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 In C++17 this bullet was removed. Instead the move is guaranteed to be elided thanks to [dcl.init]/17.6.1: If the initializer expression is a prvalue and the

This code: #include <vector> std::vector<float> getstdvec() { std::vector<float> v(4); v[0] = 1; v[1] = 2; v[2] = 3; v[3] = 4; return v; } int main() { std::vector<float> v(4); for (int i = 0; i != 1000; ++i) { v = getstdvec(); } } My incorrect understanding here is that the function getstdvec shouldn't have to actually allocate the vector that it's returning. When I run this in valgrind/callgrind, I see there are 1001 calls to malloc; 1 for the initial vector declaration in main, and 1000 for every loop iteration. What gives? How can I return a vector (or any other object) from a function

Lots of discussions here about when RVO can be done but not much about when it is actually done. As stated may times, RVO can not be guaranteed according to the Standard but is there a way to guarantee that either RVO optimization succeeds or the corresponding code fails to compile? So far I partially succeeded to make the code issue link errors when RVO fails. For this I declare the copy constructors without defining them. Obviously this is neither robust nor feasible in the non rare cases where I need to implement one or both copy constructors, i.e. x(x&&) and x(x const&) . This brings me to

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