From: Pascal J. Bourguignon on
"Alexei A. Frounze" <alexfrunews(a)gmail.com> writes:

> 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?

Indeed. For example, the Duff device is worse than most gotos I've
ever seen.

--
__Pascal Bourguignon__
From: Leigh Johnston on


"spinoza1111" <spinoza1111(a)yahoo.com> wrote in message
news:051fa27d-5cf8-4f7e-94c8-e9e5b26566b7(a)g34g2000pro.googlegroups.com...
> On Apr 24, 6:06 pm, Ali Karaali <ali...(a)gmail.com> wrote:
>> I use goto to break nested for loops and I can't see a
>> reason to ban goto.
>
> Why not use break instead? Does the same thing, spares you from having
> to define a label.
>

Because break only breaks out of the innermost loop, using goto to break out
of nested loops is one of the few sensible uses of goto.

/Leigh

From: Rui Maciel on
io_x 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

I see there is a small misconception in this issue. The only nasty thing that is usually
said about goto is that it's use may end up generating code which isn't easy to read, to
interpret and to follow.

Adding to that, high level languages implement multiple flavors of conditionals and loops,
which end up performing the exact same tasks goto is used for but in a way which is
"cleaner", easier to read, to interpret and to follow.

Yet, loop/conditionals aren't and be all, end all solution. Some tasks, such as state
machines, can still be better implemented with the plain old goto, sometimes in a "cleaner"
way than with any mix of loop/conditionals which are available in any high level language.

So, in essence, goto isn't the problem nor is it a problem. It's just a way of performing
certain tasks. Sometimes it isn't the best tool and sometimes it isn't the worst tool.
Nonetheless, that doesn't make it bad.

On the other hand, popular misconceptions which are often cited but aren't based on any
objective reasoning can constitute a problem, and this appears to be one of those cases.



Rui Maciel
From: Daniel T. on
"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

This is probably a troll, but it is a good opportunity to suggest to
everyone who is tempted to argue about this issue to start from
Dijkstra's paper rather than simply asserting that "goto is good"
without understanding the issues involved.

http://www.u.arizona.edu/~rubinson/copyright_violations/Go_To_Considered_
Harmful.html
From: Daniel T. on
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.