Re: RFC: lalr1.cc: support move semantics

[Frank Heckenbach]

Akim Demaille wrote:

> This is my proposal to add support for move semantics to Bison.
> The commit message should be clear enough.  I'd be happy to receive
> comments/reviews.
> 
> I have added an example/variant-11.yy that _requires_ move semantics
> for some of its semantics values.  Please, check it.

Just a quick reading (sorry, don't have much time ATM):

>     Symbols (terminal/non terminal) are handled by several functions that used
>     to take const-refs, which resulted eventually in a copy pushed on the 
> stack.
>     With modern C++ (post C++11),

"Post" could be understood as ">" rather than ">=" as intended.

>     move semantics allows to avoid some of these
>     copies.

More precisely, all of them (otherwise move-only types wouldn't
work).

>     That's easy for inner types, when the parser's functions pass arguments to
>     each other.  Funtions facing the user (make_NUMBER, make_STRING, etc.)
>     should support both rvalue-refs (for instance to support move-only types:
>     make_INT (std::make_unique<int> (1))), and lvalue-refs (so that we can 
> pass
>     a variable: make_INT (my_int)).  To avoid the multiplication of the
>     signatures (there is also the location), let's take the argument by copy.

By copy? Do you mean by value? (Maybe these terms were used
synonymously pre-C++11, but in the presence of move semantics I
think it's better to distinguish them clearly; same for the naming
of YY_COPY.)

> +  // Koening look up will look into std, since that's an std::vector.

Koenig (or ADL).

> +  template <typename... Args>
> +  ustring
> +  make_ustring (Args&&... args)
> +  {
> +    // std::make_unique is C++14.
> +    return std::unique_ptr<std::string>(new 
> std::string(std::forward<Args>(args)...));
> +  }

>From that template it's not a far way to a full make_unique<T>
implementation you could define conditional on C++<14.

(And FWIW, not sure if "ustring" is an ideal name for
unique_ptr<string>. My own code uses "ustring" for Unicode strings,
as does glib, AFAICS.)

> --- a/tests/c++.at
> +++ b/tests/c++.at
> @@ -151,8 +151,12 @@ int main()
>  
>    // stack_symbol_type: construction, accessor.
>    {
> +#if defined __cplusplus && 201103L <= __cplusplus
> +    auto ss = parser::stack_symbol_type(1, parser::make_INT(123));
> +#else
>      parser::symbol_type s = parser::make_INT(123);
>      parser::stack_symbol_type ss(1, s);
> +#endif
>      std::cerr << ss.value.as<int>() << '\n';
>    }
>  
> @@ -161,8 +165,12 @@ int main()
>      parser::stack_type st;
>      for (int i = 0; i < 100; ++i)
>        {
> +#if defined __cplusplus && 201103L <= __cplusplus
> +        auto ss = parser::stack_symbol_type(1, parser::make_INT(123));
> +#else
>          parser::symbol_type s = parser::make_INT(123);
>          parser::stack_symbol_type ss(1, s);
> +#endif
>          st.push(ss);
>        }
>    }

Wouldn't

  parser::stack_symbol_type ss(1, parser::make_INT(123));

work in pre-C++11 too? If it takes a const-ref, a function result
should be OK, IIRC (haven't used it for a long time).

And then also in C++>11? I personally don't think "auto x = T (v);"
adds much compared to "T x = v;" anyway, and here it would avoid the
conditionals.

Regards,
Frank