[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: C++11/14
From: |
Hans Aberg |
Subject: |
Re: C++11/14 |
Date: |
Mon, 19 Jan 2015 14:28:20 +0100 |
> On 19 Jan 2015, at 11:50, Akim Demaille <address@hidden> wrote:
>
>> 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.
Right. But are there a lot of machines with outdated C++ compilers used for
Bison? - Unlike C, were old compilers used to be common.
>>> 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.
I had in mind once being C++11/C++14 mode.
>> 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.
So it may suffice to have move constructors in the class variant.
- 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, 2015/01/19
- Re: C++11/14,
Hans Aberg <=
- 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