on goto
in [General Programming]
|
From: Lie Ryan on 2 May 2010 03:25 On 05/02/10 17:13, Richard Heathfield wrote: > Juha Nieminen wrote: >> 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. > > Your paragraph, above, is a classic example. I think Juha's point is that, if you write the for-loop's conditionals so they (using your terms) "describe the condition which the loop will terminate", that will severely complicate the conditionals (compared to simply hopping out using return). So Juha's challenging you to rewrite the looping conditionals without obfuscating them.
From: Richard Heathfield on 2 May 2010 03:34 Seebs wrote: > On 2010-04-28, Richard Heathfield <rjh(a)see.sig.invalid> wrote: <snip> >> If the data are sorted, bsearch. > >> If not, why not? > > I do not normally expect something structured like a three-dimensional > array to be sorted, I expect it to be a representation of objects. Then how on earth do you /find/ anything? It's O(N^3), for pity's sake! >> 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. > > I think the point was that he was asking *you* to rewrite the example > so that the loop conditions correctly describe the conditions under which > the loop will terminate. And we all know how that will go. This is really an argument about programming philosophy. Juha seems to be in favour of the shortest code that does the job. I'm in favour of code that accurately describes what it's doing. while(i < j) is not an accurate description of the loop if you bomb out as soon as a[i] is 42. Why not just write while(i < j && a[i] != 42)? <snip> -- 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 2 May 2010 03:40 Willem wrote: > Richard Heathfield wrote: > ) 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. > > Don't be silly. > > 'loop conditions should correctly describe the conditions under > which the loop will terminate' is a requirement that is roughly > equivalent to 'you should never exit from within a loop'. > > In other words, you're begging the question. Yes, and this question-begging is perfectly in keeping with the requirement that one should never exit from within a loop. (It is, after all, an argument about loops.) -- 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 2 May 2010 03:58 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: >>> 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. > > Your paragraph, above, is a classic example. You know, an answer of "no, you are" is rather childish. How about presenting some actual arguments instead? I gave you a piece of code and asked you to modify it to conform to your principles. You did not do that. Who is trying to avoid answering to a challenge here? >> 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". > > That's the problem. > >> Of course they do. > > No, they don't. Then why do you refuse to tell how the loops should have been written to conform to your specifications? I explicitly asked you to modify the code so that it would. Why are you refusing to do so? >> Is this just another attempt at wiggling yourself out >> of actually giving the answer? > > No, it's an attempt at wiggling *your*self out of fixing your code. Fixing my code? Oh, so there's a bug in it? Kindly point out what the bug is, please. Or are you using the word "fixing" to mean "convert it to conform my views of how loops should be written"? If yes, then why are you asking *me* to do that? I don't know what *you* want the loops to look like. I'm *asking* you to explain it to me, with an actual example. Why are you refusing to do so? Why are you demanding me to guess wildly what is it that you want the code to look like? Can you even answer that question? Why are you refusing to show me your way of writing those loops? >> 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? > > What has pride got to do with it? It's common sense, that's all. The > simplest way (and one of the fastest) to get from Tower Bridge Approach > to St Katharine's Way is to jump off the bridge, but that doesn't > necessarily mean it's the /best/ way. Then kindly show me this "best way".
From: Juha Nieminen on 2 May 2010 04:04
In comp.lang.c++ Richard Heathfield <rjh(a)see.sig.invalid> wrote: > Seebs wrote: >> On 2010-04-28, Richard Heathfield <rjh(a)see.sig.invalid> wrote: > > <snip> > >>> If the data are sorted, bsearch. >> >>> If not, why not? >> >> I do not normally expect something structured like a three-dimensional >> array to be sorted, I expect it to be a representation of objects. > > Then how on earth do you /find/ anything? It's O(N^3), for pity's sake! Are you saying that if an algorithm is O(N^3) it cannot find anything? Because that's exactly how I'm interpreting your sentence above. I would really like to see some kind of proof of that. (And what exactly does the computational complexity have to do with how you exit nested loops cleanly? Is this some kind of intentional sidetracking in order to get away from the actual subject?) >> I think the point was that he was asking *you* to rewrite the example >> so that the loop conditions correctly describe the conditions under which >> the loop will terminate. > > And we all know how that will go. So you really are refusing to answer my question and instead demanding me to guess what is it that you mean? > This is really an argument about programming philosophy. Juha seems to > be in favour of the shortest code that does the job. I'm in favour of > code that accurately describes what it's doing. while(i < j) is not an > accurate description of the loop if you bomb out as soon as a[i] is 42. > Why not just write while(i < j && a[i] != 42)? Because in many cases it makes the code more complicated than would be necessary, and in some cases even less efficient, for no obvious benefit? Are you seriously telling me that you have hard time understanding what my example code is doing, and that it would be much easier to understand in your way (whatever that might be)? |