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
