[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).
>
>
- C++11/14, Hans Aberg, 2015/01/18
- Re: C++11/14, Akim Demaille, 2015/01/19
- Re: C++11/14, Hans Aberg, 2015/01/19
- Re: C++11/14,
Akim Demaille <=
- Re: C++11/14, Hans Aberg, 2015/01/19
- Re: C++11/14, Akim Demaille, 2015/01/19
- Re: C++11/14, Hans Aberg, 2015/01/19
- Re: C++11/14, Hans Aberg, 2015/01/19
- Re: C++11/14, Akim Demaille, 2015/01/20
- Re: C++11/14, Hans Aberg, 2015/01/20
- Re: C++11/14, Hans Aberg, 2015/01/20
- Re: C++11/14, Hans Aberg, 2015/01/20
- Re: C++11/14, Hans Aberg, 2015/01/19