bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++11/14


From: Akim Demaille
Subject: Re: C++11/14
Date: Mon, 19 Jan 2015 11:50:35 +0100

> Le 19 janv. 2015 à 11:18, Hans Aberg <address@hidden> 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).
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]