on goto
in [General Programming]
|
From: Nick Keighley on 28 Apr 2010 07:40 On 28 Apr, 10:13, Richard Heathfield <r...(a)see.sig.invalid> wrote: > Nick Keighley wrote: > > check out Richard Heathfield's posting history he's a confirmed single- > > entry-single-exit man (like spinoza). > > If that's true (and it might well be true) about "spinoza", then I find > it mildly interesting, but no more than that. He uses (a kind of) > English, too, but that doesn't make English a poor choice of language. > > > I don't happen to agree but > > there's no point in arguing about it. > > Probably true. The problem is rather like that of threading vs state > machines. State machine advocates claim that threading is for people who > can't write state machines, and threading advocates claim that state > machines are for people who can't understand threading. > > SESE works for me. Clearly, multiple exits work for Juha. Since we don't > work on the same code base, let us celebrate this cultural diversity > instead of arguing about it. :-) that's what i meant about "not arguing". I'm happy to discuss my opinion and coding practices on SESE etc. To lay out the pros and cons of the different approaches but in the end there is an amount of "taste" involved in the final descision. Its arguments about "taste" I find pointless. That is why I suggested he read your backposts you've stated your opinion clearly in the past and argued your points well. -- Unpredictability may be exciting, but I don't believe it constitutes good programming practice. Richard Heathfield
From: Daniel T. on 28 Apr 2010 07:55 Phil Carmody <thefatphil_demunged(a)yahoo.co.uk> wrote: > "Daniel T." <daniel_t(a)earthlink.net> writes: > > > The debate is not the false dichotomy that some try to make it out > > to be. > > It's odd that you appear to have attempted to push it towards a > dichotomy with the above. Not at all. I specifically picked strychnine because it is something that can be taken (but it's far from common.) I am simply pointing out that there are degrees, and the debate is about degrees, not about throwing a switch. Three examples have been presented using your analogy, water, salt, and strychnine. The question is, which is goto more like? The question isn't "whether" goto is safe to use, but "how safe is it." Are better alternatives available?
From: Daniel T. on 28 Apr 2010 07:58 Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > 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 "On doctor's advice," how would that fit in the analogy? Maybe "upon extensive peer review, a consensus was reached that goto was the best alternative in this context."
From: SG on 28 Apr 2010 08:00 On 28 Apr., 11:02, Richard Heathfield wrote: > Juha Nieminen wrote: > > Richard Heathfield wrote: > >> Juha Nieminen 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'? > I wasn't planning on "meddling" with anything. I was planning on writing > appropriate loop conditions. [snip] > > 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; > > } [snip] > In any case, your loop condition expressions do not correctly describe > the conditions under which the loop will terminate. This was probably intentional. Expressing it "correctly" forces you to write slightly more comprex loop conditions which contain some kind of "i'm done"-flag like this: Value_t* MyClass::findValue(const Value_t& value) { Value_t* result = 0; for(size_t xInd = 0; !result && xInd < data.size(); ++xInd) for(size_t yInd = 0; !result && yInd < data[xInd].size(); ++yInd) for(size_t zInd = 0; !result && zInd < data[xInd] [yInd].size(); ++zInd) { if(data[xInd][yInd][zInd] == value) result = &data[xInd][yInd][zInd]; } return result; } I don't know about you but I like the first version better. It's more concise. I find it easier to see what the loop's doing. Maybe it's just me. I guess I'm used to these kinds of loops. > Please rewrite your example so that they do, [...] That's the point. You don't *have* to write them "correctly". You can get away with simpler conditions and without introducing otherwise unnecessary flags. Cheers, SG
From: Daniel T. on 28 Apr 2010 08:59
In article <dbac22e7-4667-485e-b829-2505e2bd948d(a)q23g2000yqd.googlegroups.com>, SG <s.gesemann(a)gmail.com> wrote: > On 28 Apr., 11:02, Richard Heathfield wrote: > > Juha Nieminen wrote: > > > Richard Heathfield wrote: > > >> Juha Nieminen 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'? > > I wasn't planning on "meddling" with anything. I was planning on writing > > appropriate loop conditions. > > [snip] > > > > 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; > > > } > > [snip] > > > In any case, your loop condition expressions do not correctly describe > > the conditions under which the loop will terminate. > > This was probably intentional. Expressing it "correctly" forces you to > write slightly more comprex loop conditions which contain some kind of > "i'm done"-flag like this: > > Value_t* MyClass::findValue(const Value_t& value) > { > Value_t* result = 0; > for(size_t xInd = 0; !result && xInd < data.size(); ++xInd) > for(size_t yInd = 0; !result && yInd < data[xInd].size(); > ++yInd) > for(size_t zInd = 0; !result && zInd < data[xInd] > [yInd].size(); > ++zInd) > { > if(data[xInd][yInd][zInd] == value) > result = &data[xInd][yInd][zInd]; > } > return result; > } > > I don't know about you but I like the first version better. It's more > concise. I find it easier to see what the loop's doing. Maybe it's > just me. I guess I'm used to these kinds of loops. Since the sample code is obviously in c++, I would rather see something like: Iterator it = data.begin() while(it != data.end() && *it != value) ++it; return it != data.end(); |