copy-elision

问题 i was fooling around with the following code and got different results using my visual studio 2017 application and two different online compilers. in release mode visual studio does elide the copy/move in both cases, while the two online compilers just do it in case of the unparenthesized return statement. my question is: who is right and more importantly what are the underlaying rules. (i know you can use the parentheses in conjunction with the decltype(auto) syntax. but this is not the

问题 Consider the following code: #include <iostream> using namespace std; class A { public: int a; A(): a(5) { cout << "Constructor\n"; } A(const A &b) { a = b.a; cout << "Copy Constructor\n"; } A fun(A a) { return a; } }; int main() { A a, c; A b = a.fun(c); return 0; } The output of the above code with g++ file.cpp is: Constructor Constructor Copy Constructor Copy Constructor The output of the above code with g++ -fno-elide-constructors file.cpp is: Constructor Constructor Copy Constructor Copy

问题 Consider this code: #include <iostream> using namespace std; struct Foo { public: int _a{}; Foo(int a) : _a{a} { std::cout << "ctor" << std::endl; } Foo(const Foo &) { std::cout << "copy" << std::endl; } }; int main () { Foo a{10}; Foo b = 10; std::cout << b._a << std::endl; } When I compile with g++ -std=c++11 -fno-elide-constructors test.cpp the output is ctor ctor copy 0 which is what I expect, since the in Foo b = 10 , 10 is implicitly constructed from int , then b is copy constructed

问题 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

问题 I'm still a rookie programmer, I know that premature optimization is bad, but I also know that copying huge stuff around is bad, as well. I've read up on copy elision and it's synonyms but the examples on Wikipedia for example make it seem to me that copy elision can only take place if the object to be returned gets returned at the same time it gets completely constructed. What about objects like vectors, which usually only make sense when filled with something, when used as a return value.

问题 If I understood correctly, starting from C++17, this code now requires that no copy will be done: Foo myfunc(void) { return Foo(); } auto foo = myfunc(); // no copy Is it also true for function arguments? Will copies be optimized away in the following code? Foo myfunc(Foo foo) { return foo; } auto foo = myfunc(Foo()); // will there be copies? 回答1: In C++17, prvalues ("anonymous temporaries") are no longer objects. Instead, they are instructions on how to construct an object. They can

问题 If I understood correctly, starting from C++17, this code now requires that no copy will be done: Foo myfunc(void) { return Foo(); } auto foo = myfunc(); // no copy Is it also true for function arguments? Will copies be optimized away in the following code? Foo myfunc(Foo foo) { return foo; } auto foo = myfunc(Foo()); // will there be copies? 回答1: In C++17, prvalues ("anonymous temporaries") are no longer objects. Instead, they are instructions on how to construct an object. They can

问题 Is there any warning , which allows us to know whether NRVO/RVO performed or not, in GCC ? I found that -fno-elide-constructors turns off NRVO/RVO , but NRVO/RVO has its own conditions to occur and sometimes does not occur. There is a need to know if NRVO/RVO occurs to understand, when extra copy-construction happens. I am especially interested in compile-time features. It would be nice if there were some specific #pragma GCC... (which activates the diagnostic immediately following itself) or

问题 (This is a follow-up from "Are there any realistic use cases for `decltype(auto)` variables?" ) Consider the following scenario - I want to pass a function f to another function invoke_log_return which will: Invoke f ; Print something to stdout ; Return the result of f , avoiding unnecessary copies/moves and allowing copy elision. Note that, if f throws, nothing should be printed to stdout . This is what I have so far: template <typename F> decltype(auto) invoke_log_return(F&& f) { decltype

问题 I was reading the documentation for std::for_each here http://en.cppreference.com/w/cpp/algorithm/for_each and saw that the return value is std::move(f) Why does the standard enforce moving the input parameter in the return value? Won't it be moved by default anyway, since the input parameter is passed by value? This leads me to a couple of followups, when you compile the following code Something function(Something something) { return something; } The return statement is a move on my system