> Le 19 janv. 2015 à 11:18, Hans Aberg <haber...@telia.com> a écrit : > >> I will stick to C++98 in the generated parsers. > > Compilers move much faster now: a few years both GCC & Clang were shaky on > C++11, but now, the latter works without a hitch.
The problem is not compilers, but what is installed on existing machines. > >> Yet, I agree, >> it would be nice to find the spots in the generated code where, >> using some #if checks, std::move could be used. > > Perhaps there might be a better method than macros. No, there is currently no alternative to generate C++98/C++11/C++14 dependent code. > Perhaps it is not needed: the compiler inserts std::move in code like: > int main () { > A a, b, c, d, e; > e = a*b + c*d; Well, this is an rvalue, so it is expected to move the result. > return 0; > } > The operators I get are in sequence: > a*b > c*d > a*b + c*d > r = std::move(a*b + c*d) // r = return value of ‘*' > ~A(a*b + c*d) > e = std::move® > // And destructors: > ~A(r) ~A(c*d) ~A(a*b) ~A(e) ~A(d) ~A(c) ~A(b) ~A(a) > > Here, the compiler realizes that r will not be needed anymore, so it uses > std::move(r). > >