From: Rod Pemberton on
"Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message
news:59eed8de-fa97-42f9-8550-8154ac69a167(a)h16g2000prf.googlegroups.com...
>
> If you restrict the use of goto in C/C++ to several simple patterns
> and write your code carefully, goto's aren't really a problem.
>

But, are goto's of any advantage in C over other solutions? With
optimization and good code structuring, is there any place that a goto is
the best choice?

"break" and "continue" function like goto's - without needing goto labels...
If "break" is used with "while(0)" code block, it is functionally the same
as using a forward goto. "continue" can be used for a backward goto...

IMO, this means simple usage of goto is no better than using structured C
control flow. That leaves more complicated situations where goto might have
some advantage.

The most common arguments for their use is 1) to break out of multiple, say
three or more, nested loops or 2) error recovery. Status flags,
fall-through, using a switch, restructuring the code blocks, reducing the
number of loops, can all be used to fix such problems. Is there some
situation that really advantages a goto?...

C has a robust flow control syntax. About the only thing that can't be done
readily is to detect if a while() loop was executed. The need for this is
exceptionally rare, IMO. You could use status flags, at the expense of
another variable... But, it's handled easily by adding an if() around the
while() with the same set of conditions:


A)
while(conditions)
{
/* loop stuff */
}
/* did loop execute or not? */


B)
if(identical_conditions_as_while)
{
while(conditions)
{
/* loop stuff */
}
/* if here, loop executed because */
/* conditions of if() while() are the same*/
}


> ... several simple patterns ...

Like?


Rod Pemberton



From: Rui Maciel on
Rod Pemberton wrote:

> But, are goto's of any advantage in C over other solutions? With
> optimization and good code structuring, is there any place that a goto is
> the best choice?

Yes, finite state machines. You can do those by putting a switch() on a loop but in the end
that is nothing more than a crude hack used to desperately (and irrationally) avoid using
goto.


Rui Maciel
From: Robert Redelmeier on
In alt.lang.asm Rod Pemberton <do_not_have(a)havenone.cmm> wrote in part:
> But, are goto's of any advantage in C over other solutions?
> With optimization and good code structuring, is there any
> place that a goto is the best choice?
>
> "break" and "continue" function like goto's - without needing
> goto labels... If "break" is used with "while(0)" code
> block, it is functionally the same as using a forward goto.
> "continue" can be used for a backward goto...
>
> IMO, this means simple usage of goto is no better than using
> structured C control flow. That leaves more complicated
> situations where goto might have some advantage.


Precisely! In small [teaching] examples, GOTO looks obviously
messy, confusing, "jumpy" and what have you. IOW, harmful [Dijkstra]

But structure _does_not_ scale! One if..then..else or case()
looks great. But when you have them 9 deep they are marching off
the page (formatting is a big part of the additional clarity)
and [worse], a bug in the substructures has the potential to
mess up the overall control flow. Misnesting.

GOTO _is_ messy. But it scales -- just lookup the target in
the symbol table. You do _not_ need to parse or worry about
any intervening code.

As a concrete example of the unsung benefits of GOTO, please
consider a text editor with letter commands. In C you'd do
this as a case() or switch() statement. It will be huge since
each of the commands may be quite involved. A structural bug
in (a) could affect (b). The compile may catch some of these,
but cannot when they are "paired", even far apart. A compiler
should not be used as a debugging tool.

In ASM (or C if it'll do this), you'd implement via a jmp table
(`jmp [ebx]`) and terminate each of the letter functions with
`jmp keyloop`. Or the equivalent call [ebx]/ret. More or
less how the C compiler will code it anyways.

obTroll: In many ways, GOTO is reminiscent of the slightly
more recent calculator debate between fans of TI algebraic
notation and HP reverse polish notation.


-- Robert

From: Alexei A. Frounze on
On Apr 26, 2:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:
> "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote in messagenews:59eed8de-fa97-42f9-8550-8154ac69a167(a)h16g2000prf.googlegroups.com...
>
>
>
> > If you restrict the use of goto in C/C++ to several simple patterns
> > and write your code carefully, goto's aren't really a problem.
>
> But, are goto's of any advantage in C over other solutions?  With
> optimization and good code structuring, is there any place that a goto is
> the best choice?
>
> "break" and "continue" function like goto's - without needing goto labels....
> If "break" is used with "while(0)" code block, it is functionally the same
> as using a forward goto.  "continue" can be used for a backward goto...

while(0 /*shouldn't it actually be 1 because with 0 it won't execute
even once*/) looks like a legitimate loop at first until you have
found that all the breaks out of it. What's worse it introduces an
extra nesting level, so, if there's another loop inside, breaking out
the inner one won't be as simple as still doing goto -- you'll still
have to implement some variables or whatnot in order to do what a
single goto would.

> IMO, this means simple usage of goto is no better than using structured C
> control flow.  That leaves more complicated situations where goto might have
> some advantage.
>
> The most common arguments for their use is 1) to break out of multiple, say
> three or more, nested loops or 2) error recovery.  Status flags,
> fall-through, using a switch, restructuring the code blocks, reducing the
> number of loops, can all be used to fix such problems.   Is there some
> situation that really advantages a goto?...

I'm using goto almost exclusively for the above two scenarios. For
everything else its ifs and switches (and ?: at times).

> C has a robust flow control syntax.  About the only thing that can't be done
> readily is to detect if a while() loop was executed.  The need for this is
> exceptionally rare, IMO.  You could use status flags, at the expense of
> another variable...  But, it's handled easily by adding an if() around the
> while() with the same set of conditions:

Yeah. But if you're linearly searching for something, then you begin
with an invalid index or NULL pointer and after the loop you just
examine it and see whether it has become valid or not and you don't
always need an extra variable.

Alex
From: Rod Pemberton on
"Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message
news:3175dd42-6ff2-452b-af2e-93de277ec661(a)t14g2000prm.googlegroups.com...
On Apr 26, 2:06 am, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:
>
> while(0 /*shouldn't it actually be 1 because with 0 it
> won't execute even once*/)
>

Eee... Good catch! Sorry, that doesn't work.

But, no, definately not "while(1)"... That'd would be a loop. How about
"do {} while(0)"... With a "break" or "continue", we should have a forward
or backward goto. If the "break" or "continue" is not executed, the entire
section only executes once, as if the "do {} while(0)" was not there.
Hopefully, that's correct this time?

:-)


Rod Pemberton