[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 18:33:31 +0200

> On 16 Sep 2018, at 17:38, Frank Heckenbach <address@hidden> wrote:
> Hans Åberg wrote:

>>> (*) 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.
> As I said, this already happens in "$$ = foo ();" (automatially) and
> "$$ = std::move ($k);" (whether the move is explicit or
> automatically inserted as we're discussing). So if $k is covered, no
> special handling for $$ seems necessary.

You can do it by hand, but the case I considered was to find an automated 
approach without explicitly calling std::move in $$ = $k. But your case is 

>> 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.
> Yes, perhaps we should ignore the issue for now and hope for
> compilers to offer such a warning in the future (which would be more
> useful anyway, since it would work for all code, not only Bison
> grammars).

You might make, for debugging purposes, a simplified version of a reference 
count, a boolean that tells whether the object has been moved, and issue an 
error if moved again, or otherwise just have a moved from state with such a 

This illustrates the problem with make_pair($x, $x): one may try a reference 
count or GC, but C++ does not support the implementation of a GC, even though 
the compiler has the required information, it is not accessible from the 

>>> 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?
> The type system wouldn't change. Just an additional check:
>  expr: expr '+' expr { $$ = $1; };
> Obviously one forgot to use $3 here which has a type (unlike $2
> which doesn't have a type and so is not expected to be used).
> Bison could detect and warn about this (proably optional, since I
> guess some people declare semantic types that are only meant to be
> used sometimes).

I use explicitly named variables, which guards against using the wrong $k 
number when changing a rule:
  expr: expr[x] "+" expr[y] { $$ = $x + $y; };

It would then, I gather, be easy to warn if such explicit name are unused, as 
Bison already checks if one is using undefined names.

reply via email to

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