From: Moi on 24 Apr 2010 14:00 On Sat, 24 Apr 2010 13:06:44 -0400, Daniel T. wrote: > spinoza1111 <spinoza1111(a)yahoo.com> wrote: >> On Apr 24, 11:46 pm, "bartc" <ba...(a)freeuk.com> wrote: >> > "Daniel T." <danie...(a)earthlink.net> wrote: >> > > Ali Karaali <ali...(a)gmail.com> wrote: >> > >> >> It's not a question of how far you have to look. It is a question of >> minimal preconditions. If you have a go to even in a small program, the >> code that follows it has a larger set of preconditions. > > Could you go into more detail? Maybe with some examples? IMHO the *readability* of "goto cleanup;" is not basically different from a function call "do_cleanup();". A function does not check its preconditions either. In both cases the programmer can choose a name for the function or label. And that name may or may not reflect its purpose. AvK
From: Seebs on 24 Apr 2010 14:26 On 2010-04-24, Daniel T. <daniel_t(a)earthlink.net> wrote: > I'll give you a reason to ban goto. This is a line of BASIC code: > > 90 x = 5 > > Now, I ask you, where is the line that was previously executed? Is it > directly above line 90, is it directly below it, or could it be anywhere > in the program? Because of the goto statement, simply because an > unstructured "goto" is possible in the language, you have to analyze the > entire program to know the answer. If we ban the use of "goto", we can > confidently know exactly what line of code comes before line 90. That's a great reason, but it's got nothing to do with C. In C, only other code within the same function can have gone to this line, and that only if there is a label immediately before this line. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Pascal J. Bourguignon on 24 Apr 2010 14:31 "Daniel T." <daniel_t(a)earthlink.net> writes: > Ali Karaali <alicpp(a)gmail.com> wrote: > >> I use goto to break nested for loops and I can't see a >> reason to ban goto. > > I'll give you a reason to ban goto. This is a line of BASIC code: > > 90 x = 5 > > Now, I ask you, where is the line that was previously executed? Is it > directly above line 90, is it directly below it, or could it be anywhere > in the program? Because of the goto statement, simply because an > unstructured "goto" is possible in the language, you have to analyze the > entire program to know the answer. If we ban the use of "goto", we can > confidently know exactly what line of code comes before line 90. You have to EXECUTE the entire program before knowing where you came from, thanks to computed GOTOs :-) -- __Pascal Bourguignon__
From: Richard on 24 Apr 2010 14:41 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-04-24, Daniel T. <daniel_t(a)earthlink.net> wrote: >> I'll give you a reason to ban goto. This is a line of BASIC code: >> >> 90 x = 5 >> >> Now, I ask you, where is the line that was previously executed? Is it >> directly above line 90, is it directly below it, or could it be anywhere >> in the program? Because of the goto statement, simply because an >> unstructured "goto" is possible in the language, you have to analyze the >> entire program to know the answer. If we ban the use of "goto", we can >> confidently know exactly what line of code comes before line 90. > > That's a great reason, but it's got nothing to do with C. In C, only It's a ridiculous reason. The search for the goto LABEL is trivial and a goto is often a LOT more obvious that some convoluted condition based branch using lots of nested brackets. > other code within the same function can have gone to this line, and that > only if there is a label immediately before this line. > > -s There is nothing wrong with Gotos when used in a controlled and intelligent manner. Like the bullshit about single return points the idea that gotos should not be used is generally just from 3rd rate students who think it proves they program "structured" .... -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Alexei A. Frounze on 24 Apr 2010 15:00
On Apr 24, 10:48 am, "io_x" <a...(a)b.c.invalid> wrote: > "Alexei A. Frounze" ha scritto nel messaggionews:9aedd878-0ccc-4f4a-b522-7e80b96f5fc5(a)m25g2000prj.googlegroups.com... > > > > >On Apr 24, 3:13 am, "io_x" <a...(a)b.c.invalid> wrote: > >> [Xpost to: alt.comp.programming, alt.lang.asm, > >> comp.lang.c, comp.lang.c++, comp.programming] > > >> the people that speak not good about "goto" > >> are uttled wrong; their code bug full etc > > >> more distant is your code from goto > >> more your code is bug full and incompresible > > >> the "goto" is the key word for programming; > >> all the remain, other than goto or jmp or jc or jz, > >> and the easy cpu layout > >> is the wrong way for programming > > >> i advise all you > >> Good Morning > >Everything may be used, misused and abused, goto included. There are > >good and bad usage patterns and goto is not an exception here. I can > >list a number of other things that may be just as bad as a poorly used > >goto (or as good as a good goto). See? > > what does it mean "patterns"? Not sure what you mean here. > all programming is all about choose the right gotos If your programs consisted only of gotos (as I infer from the above), they would be useless. Programming is not all about choosing the right gotos. Less so all programming. It's about many more things. Alex |