on goto
in [ASM]
|
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: 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();
From: gwowen on 28 Apr 2010 11:22 On Apr 28, 12:19 pm, Juha Nieminen <nos...(a)thanks.invalid> wrote: > Or in less words: "What's the simplest way of exiting nested loops?" > You simply attempted to evade that question by nitpicking on irrelevant > details of the example code. Juha Nieminen, meet Richard Heathfield.
From: Alexei A. Frounze on 28 Apr 2010 11:52
On Apr 28, 2:13 am, Richard Heathfield <r...(a)see.sig.invalid> wrote: .... > 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. How's that? I think some problems can't be solved (at all or easily) with one of the two. And at times both are necessary. Alex |