From: Moi on
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
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
"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
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
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