bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatially move from $n (was: C++11 move semantics)


From: Frank Heckenbach
Subject: Re: Automatially move from $n (was: C++11 move semantics)
Date: Sun, 16 Sep 2018 00:18:38 +0200

Hans Åberg wrote:

> >> But you can't safely or in general have Bison writing $$ =
> >> std::move(a) directly as one might do something else to a
> >> afterwards.
> > 
> > It would be safe if Bison checked that it's used only once in the
> > action.
> 
> But in view of that is complicated, I was playing along with idea
> to somehow using C++ to recognize it. The only way seems to use
> function calls and return, as assignments can be applied more than
> once. So the idea is that if Bison now writes

>   switch (yyn) {
>     ... 
>     case k:
>     {
>       ...
>     }   
>   }
> where the action may have $$ = ..., one has
>     case k:
>       $$ = std::move(action_k(...));
> where the action_k is some function where one returns the value instead. I'm 
> not sure exactly how to pick it together, perhaps fitting a lambda capture
>     case k:
>       auto action_k = [...](){ ... return ...; };
>       $$ = std::move(action_k(...));

I think you're at "$$" again rather than "$1" etc. I think we had
cleared that up.

> >> So a way to make it safe is to jump out of the action statement.
> > 
> > Not necessarily: You could use it twice within one expression
> > (unsafe even with jump)
> 
> That would probably not be possible, if one gets an automated break after it.

Sure it's possible: "make_pair ($1, $1)". Don't do that with
automatic move!

> > or just not use it twice (safe even without
> > jump).
> 
> But then one has to find a way to guard against that.

So far, the guard would have to be the programmer. (Which is not
completely different from explicit std::move where one also needs to
be careful. C++ is not BASIC. ;)

If Bison can detect it automatically, that would be nice, but
otherwise demanding some responsibility by the programmer seems
acceptable.

> >> But that just applies it always, which might be safe for your move only 
> >> type,
> > 
> > In fact it's safe for copy-only types, and possibly unsafe precisely
> > for movable types (move-only or move-and-copyable).
> 
> It is always unsafe with moves, unless one can find a guard against 
> unintentional reuse of a moved-from element.

"always ... unless" = "possibly" :)

Regards,
Frank



reply via email to

[Prev in Thread] Current Thread [Next in Thread]