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: Hans Åberg
Subject: Re: Automatially move from $n (was: C++11 move semantics)
Date: Sun, 16 Sep 2018 01:15:09 +0200

> On 16 Sep 2018, at 01:01, Frank Heckenbach <address@hidden> wrote:
> 
> Hans Åberg wrote:
> 
>> I realize now that you want to wrap $k with std::move and guard against 
>> reuse of that! (See below)
> 
> Yes, see $subject.
> 
>>> 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 $$.
> 
> Again, the assignment to $$ is <bold>*NOT*</bold> the issue! (*)
> It's the passing (moving) of $k.
> 
> (*) Nitpick: Except in a case like "$$ = $2;", but then I'd argue
>    it's the passing of $2 to $$'s assignment operator that's the
>    issue. :)

Maybe not for you, but for a more normal use, with types having both copy and 
move. Then one would like to use move to $$ whenever possible. Doesn't matter 
with me, as it is just some pointers and integers.

>> Maybe there is some more general C++ code checking program that
>> can be linked into Bison to check the  actions.
> 
> You mean some kind of code analyzer? This might be possible, but may
> be overkill.

Yes, you might check how people do check against that problem, if there is some 
program doing that. Then one might get ideas of how to get into Bison.

Perhaps it might be possible to have some DLL or external program and invoke 
that.

> Bison could keep track if any $k is used several times
> and warn about that; though it may give false positives in cases
> such as:
> 
>  $$ = $1 ? foo (move ($2)) : bar (move ($2));  // safe
> 
> But the user could work around such (hopefully) rare cases with a
> temporary variable holding move ($2).
> 
> Or can code analyzers recognize the above as safe? (Do you have
> experience with any?)

No, but it seems me it is a hard problem. A compiler optimizer can recognize 
such things if it has sufficient information about the types, by tracing the 
code flow.

> On the same token, Bison could then also (optionally) warn if some
> $k which has a type is not used. I don't know if there is interest
> in such a feature. It could also be useful for other languages.
> 
> It might not be too hard to do for someone who's familiar with
> Bison's internals. (Unfortunately, I'm not very much, and don't have
> much free time right now.)

How would this be different from the current static type system?





reply via email to

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