> On 18 Sep 2018, at 00:20, Frank Heckenbach <[email protected]> wrote: > > Hans Åberg wrote: > >>>> Yes, indeed C++ does not support that, >>> >>> Are you replying to your own statement now? I never claimed (or >>> cared) whether C++ supports GC. >> >> C++ does not support the implementation of a (tracing) GC, because >> the information needed, though available to the compiler, is not >> available from the language. The fact that it does not have a GC >> is another topic. > > I know and (again) I don't care because I don't want to use GC > anyway. You're basically discussing with yourself here.
It exemplifies the of limitations C++. See below. >>> At runtime, yes. Basically an extended unique_ptr could detect this >>> automatically. >> >> This looks like becoming you option. You might use it for >> debugging only. > > My option? I'm not having this problem. So then why bother bringing it up in the first place? > Again, I only brought up the > make_pair thing as a counterexample to your claim that an automatic > break would avoid any possible double-move. You gave a counterexample of something else than what I discussed. > But it might be a solution to someone else's problem (or another > problem of mine some other day ;). Until that day, it's too esoteric to be worth implementing, in my opinion. >>> I'd rather see a compile-time check, even if it's a >>> bit primitive, i.e. gives false positives. >> >> Even though the compiler may have access to the information to >> check that, you don't have access to that from the language >> itself. Parsing the language is a long haul, even though there >> were some here wanting help with that. > > No, I don't want to go there. As said before, I see two viable > compile-time options so far: > > - Within Bison, hopefully rather easy to implement, but with some > false positives. > > - Within(!) the compiler, more general, but a job for compiler > experts, not me. You won't get that for the same reason as in the GC case above.
