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

[Frank Heckenbach]

Hans Åberg wrote:

> >>> 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'm suggesting doing it automatically (again, see subject).

> I considered having it automatically.

You focus on one special case (moving $k to $$). You seem to think
it's somehow different to moving $k to somewhere else, but you
failed to explain why this should be so. I think it's the same, so
solving the general case (moving from $k) will also solve the
special case (moving $k to $$).

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

It's you who keeps coming back to $$ again and again.

> despite I told you I now see that you are interested in  something
> else.

Not something else, just a more general case.

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

Are you replying to your own statement now? I never claimed (or
cared) whether C++ supports GC.

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

I don't think so. GC needs type information at runtime. An optimizer
needs it at compile type. I don't know if it has access to it
already (don't know gcc internals so well), but if not, providing it
is something totally different from providing it to the runtime.

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

At runtime, yes. Basically an extended unique_ptr could detect this
automatically. I'd rather see a compile-time check, even if it's a
bit primitive, i.e. gives false positives.

Regards,
Frank