on goto
in [ASM]
|
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
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: 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? |