Akim Demaille wrote:
> > 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}
>
> 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?
I would. My grammar file is much more readable with it, as it saves
me multiple std::move calls in most rules.
Of course, there's a danger of using a moved-from value. When I
introduces it, I had to check my grammars for multiple uses of the
same value which I did to a first approximation with a regex search
(something like "(\$[0-9]+).*\1"), then checked the few remaining
cases manually (but my grammar rules are rather simple; most of the
actual work is done in external functions, often just make_unique<>,
sometimes self-written ones).
As I wrote, if Bison could detect multiple uses and warn, that would
be great, but I didn't look into it as I didn't want to patch Bison
itself.
Another syntax (just for the sake of example "#1" for moving, while
keeping "$1" as is) might be an idea, but is still dangerous if one
uses $1 after #1, so probably not worth it.
So, lacking other ideas, I'd stay with api.rhs.access, which was
easy to implement and does the job for me. I certainly don't want to
put std::move everywhere in my grammar. -- In fact, if I'd
ultimately have to, I'd make make up something like "#1" and
preprocess my grammar with sed before feeding it to Bison, to keep
it readable. Seeing as Bison does lots of processing of the source
anyway, this would seem overly complicated and bizarre to me.
Regards,
Frank
