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).
> 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.)
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?
> >> 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. 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.
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.
Regards,
Frank
