> On 19 Jan 2015, at 08:50, Akim Demaille <a...@lrde.epita.fr> wrote:
>
>
>> Le 18 janv. 2015 à 23:28, Hans Aberg <haber...@telia.com> a écrit :
>>
>> C++11/C++14 seems to work really well with the compiler I am using (Apple
>> Clang on OS 10.10.2): perhaps there might be support for that in the C++
>> parser, so that $$ = x o demand translates into $$ = std::move(x). - The
>> calc++ example has lines using std::swap($$, $k), but it would be a bit more
>> efficient with $$ = std::move($k) for heavier types than the copy-over type
>> ‘int’ used.
> 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.
> 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.
> FWIW, I extensively use Bison C++ parser with variants in a C++14
> project. I works well.
I thought it might nice to do a GMP calculator, in part to check copy/move
constructors. Writing some code shows that the compiler is very efficient in
removing copying.
> And I do use std::move in my actions. But
> Bison cannot use std::move in the actions: it can't tell the use
> of $n as an lvalue or as an rvalue. Maybe playing with std::forward
> could work, yet I think it is really up to the user to qualify her
> $n as she wants. $n is really a variable, and it's up to the user
> to decide how to use it.
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;
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).
