on goto
in [General Programming]
|
From: Daniel T. on 27 Apr 2010 16:12 raltbos(a)xs4all.nl (Richard Bos) wrote: > "Daniel T." <daniel_t(a)earthlink.net> wrote: > > [ Quoting Dijkstra's "Goto considered harmful": ] > > > The unbridled use of the go to statement > > This is the one thing which Dijkstra's editor (who wrote that headline), > the War-On-Goto lobby, and even Dijkstra himself in later years, seem to > have missed. > > _Unbridled_. > > The unbridled use of salt is also deadly to humans. We must ban it > outright. > > Richard (takes a little salt, not a lot) Unbridled use of strychnine is deadly too, how much strychnine do you take? The debate is not the false dichotomy that some try to make it out to be.
From: Juha Nieminen on 28 Apr 2010 01:16 In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Juha Nieminen wrote: >> In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: >>>> Exactly how do you exit out of a set of nested loops with a "break"? >>> I don't. I exit out of a set of nested loops using the conditions in the >>> loop controllers. >> >> The idea was to make the code simpler, cleaner and easier to follow, not >> more complicated and contrived. > > Yes. That's precisely why I use the conditions in the loop controllers. Care to show an actual example of your "simpler, cleaner and easier to follow" version of exiting a nested loop by meddling with the loop conditions instead of using 'return'? For example, modify the following code to conform to your specifications: Value_t* MyClass::findValue(const Value_t& value) { for(size_t xInd = 0; xInd < data.size(); ++xInd) for(size_t yInd = 0; yInd < data[xInd].size(); ++yInd) for(size_t zInd = 0; zInd < data[xInd][yInd].size(); ++zInd) { if(data[xInd][yInd][zInd] == value) return &data[xInd][yInd][zInd]; } return 0; }
From: tonydee on 28 Apr 2010 03:12 On Apr 25, 7:47 am, James Kanze <james.ka...(a)gmail.com> wrote: > [...] in C and in > C++, for all "good" uses of goto (and a number of bad ones), the > language has specialized structures which better express the > meaning. Just not so. Much low-level state-based code is best expressed via gotos. There are a couple hundred usages spread over 7 different Boost libraries (as of 1.41). Have a look and you might find something you think reasonable. Sometimes working too much in a particular set of problem domains can either make it seem like goto isn't beneficial, or make it completely obvious it is. Parsers are one area where the uses are clear, for example: the boost regex parser. Similarly, some lexers I've written have employed gotos too... it's just cleaner. I'm pretty sure Walter Bright chipped in on an argument like this a couple years back, also supporting some uses of gotos... not somebody who's experience I'd challenge - will try to dig up the reference if anyone cares.... Cheers, Tony
From: Nick Keighley on 28 Apr 2010 03:28 On 27 Apr, 21:12, "Daniel T." <danie...(a)earthlink.net> wrote: > ralt...(a)xs4all.nl (Richard Bos) wrote: > > "Daniel T." <danie...(a)earthlink.net> wrote: > > > [ Quoting Dijkstra's "Goto considered harmful": ] > > > > The unbridled use of the go to statement > > > This is the one thing which Dijkstra's editor (who wrote that headline), > > the War-On-Goto lobby, and even Dijkstra himself in later years, seem to > > have missed. > > > _Unbridled_. > > > The unbridled use of salt is also deadly to humans. We must ban it > > outright. > > > Richard (takes a little salt, not a lot) > > Unbridled use of strychnine is deadly too, how much strychnine do you > take? The debate is not the false dichotomy that some try to make it out > to be. digitalis is a poison and quite a lot of peopel take on the doctor's advice
From: James Dow Allen on 28 Apr 2010 03:32
On Apr 28, 12:16 pm, Juha Nieminen <nos...(a)thanks.invalid> wrote: > In comp.lang.c++ Richard Heathfield <r...(a)see.sig.invalid> wrote: I'll admit my C functions tend to be overly long, but, without mentioning names, some C programmers seem to use functions that tend to be overly short! When a slightly complicated code fragment is posted, like Juha's though there are unrelated examples, an oft-seen response is "break it into smaller functions." For example foo() { for ... for ... for ...} can be built from three functions like foo1() { for ... foo2(); } *That*'s a big reason why some programmers "never need to use goto." > > Juha Nieminen wrote: > >> The idea was to make the code simpler, cleaner and easier to follow, not > >> more complicated and contrived. > > Yes. That's precisely why I use the conditions in the loop controllers. > ... For example, modify the following > code to conform to your specifications: > [ for ... for ... for ... if ... return ] As Juha is well aware, it's possible to make the code conform by making the for statements much more complicated. But when one compares the code, before and after, it's hard to see why anyone would prefer the complicated code unless they just have a dogmatic aversion to inner-returns or gotos. On Apr 28, 2:12 pm, tonydee <tony_in_da...(a)yahoo.co.uk> wrote: > Sometimes working too much in a > particular set of problem domains can either make it seem like goto > isn't beneficial, or make it completely obvious it is. This is an important point. In some ways, my experience has been fairly broad, but I've never written a real parser, a database manager, an accounting program, or a serious user interface! (Some who now laugh at my inexperience may not have written state space searchers, hardware diagnostics, compressors, kernels, graphic or image manipulations, etc.) Different applications will lead to different coding style choices. James Dow Allen |