Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c++ Subject: Re: two's complement idea Date: Sat, 04 Apr 2020 12:37:46 -0700 Organization: A noiseless patient Spider Lines: 81 Message-ID: <86o8s7nit1.fsf@linuxsc.com> References: <4hBWF.107660$LY2.60603@fx23.am4> <20200125134202.8939b7b4f1db1e1f59c1411d@cvine--nospam--.freeserve.co.uk> <86r1zlgpyx.fsf@linuxsc.com> <865zg7hpux.fsf@linuxsc.com> <86mu7u6kzx.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="962b2addb8ebbeafdd69920a30d34173"; logging-data="22465"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18L+Ttkt6y+D6MwT7xi5DCdds1K8QEwiW8=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:NWgn45Eb3JY2yX2gqWBRRctV9rw= sha1:LRuOe96ldcvygFEq1mrfyWmNnOE= Xref: csiph.com comp.lang.c++:72813 Paavo Helde writes: > On 2.04.2020 17:05, Tim Rentsch wrote: > >> Paavo Helde writes: >> >>> On 15.02.2020 16:44, Tim Rentsch wrote: >>> >>>> Paavo Helde writes: >>>> >>>>> On 27.01.2020 12:20, Tim Rentsch wrote: >>>>> >>>>>> Paavo Helde writes: >>>>>> >>>>>>> On 25.01.2020 16:58, Bart wrote: >>>>>>> >>>>>>>> How would C++ help here, to avoid either that extra logic, or >>>>>>>> the use of that goto? Here's the current outline (for_each_pwq >>>>>>>> is a macro expanding to a regular for-header): >>>>>>>> >>>>>>>> L: >>>>>>>> A; >>>>>>>> for (...) { >>>>>>>> B; >>>>>>>> if (C) continue; >>>>>>>> D; >>>>>>>> goto L; >>>>>>>> } >> >> [...] >> >>>>> BTW, in my own code I have several times encountered similar awkward >>>>> "backward goto" scenarios needed only for unlocking a mutex. And the >>>>> result has always been a mess I'm afraid. >>>> >>>> That's interesting. Is that always because of pending destructor >>>> behavior? If it is, that suggests that the RAII pattern using >>>> standard constructor/destructor semantics has some shortcomings, >>>> which may indicate a need for other behavior choices. For example, >>>> the funky() function above could be writeable using a new 'creturn' >>>> construct, written as >>>> >>>> creturn funky(); >>>> >>>> where 'creturn' means first run any pending destructors, and only >>>> after they finish execute the (implied) return statement. >>> >>> This would mess up the lifetime rules of automatic variables, meaning >>> that their lifetime would not match the visual scope any more. I'm >>> sure this would do more harm than good. >>> >>> Also, such 'creturn' would not solve the initial problems, at least >>> not in cases I have had. Effectively, what is needed is to release a >>> mutex lock temporarily in some circumstances, do something out of the >>> mutex lock, then enter the lock again. Logically this is a task for a >>> single function, any 'return' or 'creturn' would split this task into >>> two functions, which is a bit convoluted, which I think you already >>> mentioned above. >>> >>> >>>> Doing >>>> that avoids all the nested locking problems, and also makes the >>>> apparent "tail call" be a true tail call, and so could be optimized >>>> to reuse the stack frame. What other kinds of constructs might make >>>> your troublesome mutex uses more tractable? >>> >>> What would help in my case would be a command like 'retry' or >>> restart' which would destroy all automatic variables in the function >>> and restart the function again. It would be equivalent to a 'goto' to >>> a label in the start of the function, [...] >> >> It is rather amusing that you didn't like creturn, and then >> describe a construct that behaves just the way a creturn would, >> except the retry/restart construct is less general than creturn. > > That's because the main problem with the current solution (goto) is > that it is too general. That's the reason why more restricted > statements (break and continue) exist even though they could be > replaced by goto-s. goto is unstructured. return (and creturn) is structured.