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: Mon, 27 Jan 2020 01:50:05 -0800 Organization: A noiseless patient Spider Lines: 53 Message-ID: <86v9oxgrea.fsf@linuxsc.com> References: <4hBWF.107660$LY2.60603@fx23.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7c306968cf7022673062d49c54d79376"; logging-data="32427"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JqPZXZJaMRlwpKdH8Ggw7XyrWdWPPONs=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:aCwH1e08MfLyPGirsNHnT8lt1pk= sha1:/G+IKYUifnMK8o8R4Wu6dL+No3M= Xref: csiph.com comp.lang.c++:71619 Robert Wessel writes: > On Sun, 26 Jan 2020 14:58:45 +0100, David Brown > wrote: > >> On 26/01/2020 13:44, Bart wrote: >> >>> nested loop control, >> >> Gotos are most certainly not needed for that. >> >> Again, I'd suggest that if you think "goto" is necessary (in manually >> written code) to handle the flow you need, then your code structure is >> probably not ideal. >> >> And if you think it is the only efficient solution because extra tests, >> duplicated calculations, local flag variables, etc., would have a >> run-time cost, then you are not using the right tools or not using them >> in the right way. Either efficiency doesn't matter, so the cost is >> irrelevant, or you use good tools and let the compiler handle the >> optimisation from flags to gotos. It is very rare that you need maximal >> code efficiency and have no choice but to use poor tools. > > I don't think efficiency is a main concern here, or even an important > one. Rather some uses of goto are, at least IMO, clearer than many of > the alternatives. The error handling and nested-loop escape being two > common ones. C++/RAII mostly removes one of those. > > Certainly everything can be written without gotos, I just don't think > that's always the clearest way to write the code. "Clarity" being a > somewhat subjective determination, of course. A bit of code in an > unfamiliar idiom, even if simpler, can be less "clear". > > Still, gotos should be used quite sparingly. And uses should avoid > the "spaghetti" code of the distant past. > > On the other hand, this is a bit of a tempest in a teapot. When > Dijkstra wrote "Goto considered harmful", his context was unrestricted > branching across large monolithic programs (sometimes 10's of KLOCs). > The problems that introduces are just not possible if you have > reasonably sized routines. I'm not suggesting that unrestricted > branching across a 50 line routine is a good idea, but he'd never have > written that paper to deal with those issues. You just cannot have > the morass you get from a bunch of labels in a chunk of code > referenced by dozens of gotos, many from multiple thousands of lines > away. > > I just think people have gone a bit overboard with the idea, so that > it's ended up as "if there's any way to avoid a goto, do so" (which we > know is actually always possible*), rather than focusing on clarity. I give this posting my vote for the best commentary in the thread.