> Le 19 janv. 2015 à 11:18, Hans Aberg <[email protected]> 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).
>
>
