[Top][All Lists]

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

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

From: Hans Åberg
Subject: Re: Automatially move from $n (was: C++11 move semantics)
Date: Sun, 16 Sep 2018 00:42:54 +0200

> On 16 Sep 2018, at 00:18, Frank Heckenbach <address@hidden> wrote:
> Hans Åberg wrote:
>>    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.

I realize now that you want to wrap $k with std::move and guard against reuse 
of that! (See below)

>>>> 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!

Ah, your idea is to wrap std::move around the $k values! My idea is to let the 
C++ language recognise that, and then automate the assignment to $$.

If you have a move only type and want it to safe as above, then you need some 
more general C++ checking mechanism.

>>> 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.

Maybe there is some more general C++ code checking program that can be linked 
into Bison to check the  actions.

>>>> 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" :)

Indeed you have a lot of code, and then somebody sometime in the future should 
check it, perhaps yourself, and have forgotten about the details.

reply via email to

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