[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 19:36:30 +0200

> On 16 Sep 2018, at 19:16, Frank Heckenbach <address@hidden> wrote:
> Hans Åberg wrote:
>>>> 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,
> Sorry, but how does this answer anything? The subject (also thread
> subject) is explicitly: "Automatially[sic, sorry for the typo ;]
> move from $n".
> So saying "You can do it by hand" is just giving up (which is
> pointless, since I already have a solution).

It looks as though you are suggesting doing it by hand by writing $$ = 
std::move($k) instead of $$ = $k whenever necessary. I considered having it 

>> but the case I considered was to find an automated approach
>> without explicitly calling std::move in $$ = $k. But your case is
>> different.
> It's more general. "$$ = $k" is strictly a subset of the general
> case. (And IMHO not a very important one for k > 1. For k = 1, we
> can have a default action, but how often do you really need
> "$$ = $2"? In a rule like "expr = '(' expr ')';" typically, but
> that's about it.)

It happens every now and again. I have
  identifier_declaration definition[x]
where the first just defines the names and does not produce any value.

> I can't help but view your insisting on $$ as diverting from the
> actual topic. If you want to discuss any issues with moving to $$
> (whatever those issues may be; I don't see any), may I suggest you
> start a new thread, please?

You are the one keeping comping back to the issue, despite I told you I now see 
that you are interested in  something else.

>>>> 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 property.
>> 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 language.
> Hold it! We were discussing a static compiler check, and within two
> paragraphs you divert to runtime checks (which are less reliable)
> and then to GC which I dislike for many reasons. To me it seems like
> a last effort: if you can't do proper resource management (like
> RAII), let the garbage collector pick up the pieces.

Yes, indeed C++ does not support that, and it looks it is the same with your 
problem for the same reasons, which is why it is so difficult to find solutions 
within the language.

> Fact is, I can
> do proper resource management in most cases, and just said it would
> be nice to have an extra check if it's not too hard to implement.

It looks is not hard to implement such a check against double moves, and that 
might be the best solution, though it calls for more careful runtime testing.

> Also note that "make_pair($x, $x)" was just a counterexample to your
> claim that an automatic break after the statement would avoid the
> problem. It's not something I actually need to do. If I did, I could
> choose between copying in this case (if possible), using a
> shared_ptr, or whatever.

Yes of course, I have a polymorphic (virtual) ref<T> GC type that emulates T& 
holding just a non-null pointer, and one might need to clone the value 

reply via email to

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