Hans Åberg wrote: > >> 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.
Nope. Again: compile-time != runtime. > > My option? I'm not having this problem. > > So then why bother bringing it up in the first place? Funnily, I preemptively answered this question just in the next sentence that you also quoted: > > 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. Nope, you said: "So a way to make it safe is to jump out of the action statement.", I replied: "Not necessarily: You could use it twice within one expression (unsafe even with jump)", and you replied: "That would probably not be possible, if one gets an automated break after it." Then I gave an example of what I had said before, that it *is* possible to use it twice in one statement, counter to your claim. I never said it occured in my code, just explained why break isn't the solution. You can check it here: http://lists.gnu.org/archive/html/bug-bison/2018-09/msg00036.html > > 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. Esoteric I don't know, but certainly not hard to implement. Basically a flag that it set when moved from and causes an exception on any subsequent access (except assignment to, and destruction, of course). Seems like a nice student project ... :) What would be much more interesting would be a generic decorator that does this and can be applied to any type one wants to, but that's more tricky and I think impossible in current C++ because one can't wrap "any method" generically. Maybe if Herb Sutter's metaclass proposal takes off, one (far) day ... https://herbsutter.com/2017/07/26/metaclasses-thoughts-on-generative-c/ > >> Even though the compiler may have access to the information to > >> check that, you don't have access to that from the language > >> itself. > > > > - 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. And why would that be? You said yourself that "the compiler may have access to the information to check that". Regards, Frank
