> On 19 Jan 2015, at 11:50, Akim Demaille <a...@lrde.epita.fr> wrote:
>
>> 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.
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.
