on goto
in [General Programming]
|
From: Nick Keighley on 28 Apr 2010 03:33 On 28 Apr, 06:16, Juha Nieminen <nos...(a)thanks.invalid> wrote: > In comp.lang.c++ Richard Heathfield <r...(a)see.sig.invalid> wrote: > > > Juha Nieminen wrote: > >> In comp.lang.c++ Richard Heathfield <r...(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; check out Richard Heathfield's posting history he's a confirmed single- entry-single-exit man (like spinoza). I don't happen to agree but there's no point in arguing about it.
From: Phil Carmody on 28 Apr 2010 03:36 "Daniel T." <daniel_t(a)earthlink.net> writes: > 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? As a stimulant or a performance-enhancing drug, a couple of milligrams, traditionally. > 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. Phil -- I find the easiest thing to do is to k/f myself and just troll away -- David Melville on r.a.s.f1
From: Richard Heathfield on 28 Apr 2010 05:02 Juha Nieminen wrote: > 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'? I wasn't planning on "meddling" with anything. I was planning on writing appropriate loop conditions. > For example, modify the following > code to conform to your specifications: > > Value_t* MyClass::findValue(const Value_t& value) I'm reading this in comp.lang.c, but I'll give you a C parallel if you like. > { > 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; > } If the data are sorted, bsearch. If not, why not? In any case, your loop condition expressions do not correctly describe the conditions under which the loop will terminate. Please rewrite your example so that they do, and then by all means ask me again if you wish. -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Richard Heathfield on 28 Apr 2010 05:13 Nick Keighley wrote: <snip> > 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. :-) -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Juha Nieminen on 28 Apr 2010 07:19
In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: > If the data are sorted, bsearch. > > If not, why not? > > In any case, your loop condition expressions do not correctly describe > the conditions under which the loop will terminate. Please rewrite your > example so that they do, and then by all means ask me again if you wish. No offense, but it always amuses me how some C programmers try to wiggle themselves out of actually giving honest answers when they are presented with problematic situations related to their coding style, C, or both. The question was not "how would you keep this kind of data stored so that it's as fast and easy to find as possible?" That's completely besides the point. The question was "if the task, whatever it might be, is resolved in the innermost loop, and hence all the loops can be ended right away because the desired result has been retrieved, what would be the simplest way of doing that?" 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. It doesn't matter what kind of data container the routine was dealing with or how it's being searched: The relevant part was that a triply-nested loop is being performed, and the task is achieved in the innermost one. And I have no idea what you mean by "your loop condition expressions do not correctly describe the conditions under which the loop will terminate". Of course they do. Is this just another attempt at wiggling yourself out of actually giving the answer? Is it *really* that hard to simply say "yes, in this particular example the 'return' is indeed the simplest way"? Does it hurt your pride or something? |