> Le 1 avr. 2018 à 16:43, Frank Heckenbach <f.heckenb...@fh-soft.de> a écrit :
> 
> I've now changed my grammars to use my new C++17 skeletons with
> std::variant and move semantics. So far, it seems to work fine.
> 
> As expected, they now contain a lot of "std::move ($n)" expressions.
> Even though the simple case "$$ = std::move ($1)" is now covered by
> the default action, most are actually within expressions such as
> "$$ = make_foo (std::move ($1), std::move ($2))" which is less than
> perfectly readable ...
> 
> […]
> That's what I've implemented now -- except for the warning (which
> doesn't seem possible without changes to Bison itself).
> 
> In fact, rather than a Boolean option, I added a define that's
> wrapped around every $n access. (Though ATM I can't think of any
> other function except std::move one might want to use there -- maybe
> some fancy debugging stuff if Bison's trace mechanism isn't
> sufficient, or whatever ...)
> 
> By default it's empty, so it's like before, but one can e.g. add
> 
>  %define api.rhs.access {std::move}

Frank,

I would like to have your opinion on this, a few months after
having practiced the idea.  It looks great, but some ideas look
great first, and them show some limitations.

Would you recommend that we really import this into Bison?


Reply via email to