regarding "goto" in C

[M.B]

Guys,
Need some of your opinion on an oft beaten track
We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
So why goto is outlawed from civilized c programmers community.

is there any technical inefficiency in that.

Thank you

[Thad Smith]

M.B wrote:

Need some of your opinion on an oft beaten track
We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
So why goto is outlawed from civilized c programmers community.
About 1968 or so Edsger Dijkstra wrote an article, published as a Letter
to the Editor in the ACM Communications magazine, titled Go To
Considered Harmful. He observed that unrestrained use of goto--what we
now refer to as "spaghetti code"--makes a program hard to understand and
therefore often has bugs. Shortly afterwards, there was much activity
to develop a method of programming, called structured programming, that
decomposed code into neat blocks, such as iteration, sequence, and
selection, such that no gotos were needed! It caught on as a way to
organize code.

The reason it is still with us is that as a general rule is that it
still helps to prevent the spaghetti code mess. Does it always produce
more understandable code? I don't think so, although it usually comes
close. In my opinion, it is a rule that should be understood and used
well before attempting to break it.
is there any technical inefficiency in that.

In general, there is some inefficiency with the elimination of goto.
In order to eliminate goto, you often have to implement additional
variables or flags to carry information from an inner loop to the
outside in order to stop intermediate processing, which is not needed if
you simply jump directly out of a loop. Also, there tends to be some
code duplication. Some people, such as I, cheat by returning from a
function more than one place in the body, a violation of the strict
structured approach.

At the machine level, there is almost always a jump or branch
instruction that performs a goto function.

--
Thad

[Keith Thompson]

"M.B" <mb*******@gmail.com> writes:

Need some of your opinion on an oft beaten track
We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
So why goto is outlawed from civilized c programmers community.

It's not "outlawed" unless you're working with a coding standard that
forbids it.

Goto statements can easily lead to "spaghetti code". The real problem
isn't the goto statement itself; it's the label. Whenever you see a
label in code, it's very difficult to tell how the program could have
gotten there. So-called "structured programming" intstead builds a
program structure from a set of higher-level constructs, such as
if/then/else, loops, switches, and so forth.

A program's structure often corresponds to something in the real-world
entity being modeled. An if statement corresponds to a decision. A
loop corresponds to doing something repeatedly. A goto statement
corresponds to ... well, to jumping from one point in the program to
another; it rarely matches anything in the real world (unless the
program is modeling a finite state machine).

Used with care, however, they can be useful, especially as a
substitute for a control structure that's missing from the language.
C doesn't have an exception handling mechanism, so gotos can be useful
for error handling (bailing out of a nested construct when something
goes wrong). C doesn't have a multi-level break statement, so gotos
can be useful for that.

A goto statement that branches backward, or that does something that
could have been done straightforwardly with a loop, is almost always a
bad idea.

The classic essay on the topic, from 1968, is Edsger W. Dijkstra's
"Go To Statement Considered Harmful", available at
<http://www.acm.org/classics/oct95/>.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Nils O. Selåsdal]

Keith Thompson wrote:

The classic essay on the topic, from 1968, is Edsger W. Dijkstra's
"Go To Statement Considered Harmful", available at
<http://www.acm.org/classics/oct95/>.

Let's not forget
"Structured Programming with go to Statements"
http://portal.acm.org/citation.cfm?id=356640

[tmp123]

M.B wrote:

My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).

Hi,

What you say has been experienced also by lots of programmers. Error
handling is sometimes easier to do with "goto".

We could say (saving a lot of details) that in order to skip the
contradiction
between "goto's are bad" and "goto's are good for error handling", the
concept of "exceptions" has been created.

Thus, I suggest you to review the usage of "try"/"catch"/... (forget my
sugestion if you know them).

Kind regards.

[Richard Heathfield]

tmp123 said:

Thus, I suggest you to review the usage of "try"/"catch"/... (forget my
sugestion if you know them).

They don't exist in C.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[tmp123]

Richard Heathfield wrote:

tmp123 said:

Thus, I suggest you to review the usage of "try"/"catch"/... (forget my
sugestion if you know them).

They don't exist in C.

Yes, you have reason, I forget to remark it (a good reason to start in
C++).

However, I'm sure you known it is posible a workaround with a few
macros like:

#define TRY if(...(setjmp(...
#define CATCH else
#define RAISE logjmp(...

Kind regards.

[Richard Heathfield]

tmp123 said:

Richard Heathfield wrote:

tmp123 said:

> Thus, I suggest you to review the usage of "try"/"catch"/... (forget my
> sugestion if you know them).
They don't exist in C.

Yes, you have reason, I forget to remark it (a good reason to start in
C++).

No, it's not. It is a good thing to know how to write C++ programs, and also
a good thing to know how to write C programs, and it is an excellent thing
to know when to use which.
However, I'm sure you known it is posible a workaround with a few
macros like:

#define TRY if(...(setjmp(...
#define CATCH else
#define RAISE logjmp(...

I really wouldn't do that if I were you. There are subtleties to the
portable use of setjmp/longjmp which make it a non-trivial exercise.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chuck F.]

Keith Thompson wrote:

.... snip ...
A goto statement that branches backward, or that does something
that could have been done straightforwardly with a loop, is
almost always a bad idea.

The classic essay on the topic, from 1968, is Edsger W.
Dijkstra's "Go To Statement Considered Harmful", available at
<http://www.acm.org/classics/oct95/>.

See also:

<http://pplab.snu.ac.kr/courses/adv_p104/papers/p261-knuth.pdf>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Chuck F.]

tmp123 wrote:

M.B wrote:

My personal experience was that goto sometimes makes program
some more cleaner and easy to understand and also quite useful
(in error handling cases).

What you say has been experienced also by lots of programmers.
Error handling is sometimes easier to do with "goto".

We could say (saving a lot of details) that in order to skip the
contradiction between "goto's are bad" and "goto's are good for
error handling", the concept of "exceptions" has been created.

Thus, I suggest you to review the usage of "try"/"catch"/...
(forget my sugestion if you know them).

You have done a naughty thing. There is no "try/catch" in the C
language, thus they are not applicable here. In fact they are
off-topic. You might have been thinking of some other language
with a vague resemblance to C.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[John Bode]

M.B wrote:

Guys,
Need some of your opinion on an oft beaten track
We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
So why goto is outlawed from civilized c programmers community.

IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.
2. Never branch into the middle of another control structure (if, for,
while, etc.)
3. Don't use goto if another control structure can do the same job.
is there any technical inefficiency in that.

ISTR some verbiage in H&S that the presence of a goto can hinder some
compiler optimizations.

[Chuck F.]

John Bode wrote:

.... snip ...
IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.
Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;
domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if it
could the goto is clearer.
2. Never branch into the middle of another control structure
(if, for, while, etc.)
See the Knuth paper (reference from me upthread) for a
counterexample. s/Never/Almost never/
3. Don't use goto if another control structure can do the same
job.

This one I can accept.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Eric Sosman]

Chuck F. wrote:

John Bode wrote:

... snip ...

IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;
domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if it could
the goto is clearer.

Note that this can be trivially converted to a forward
branch by writing `outer: ;' just before the closing brace
of the outer loop. Note, too, that this conversion would be
necessary, not just possible, if the outer loop were a `for'
or a `do...while'.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Richard Tobin]

In article <11********************@o13g2000cwo.googlegroups.c om>,
John Bode <jo*******@my-deja.com> wrote:

1. Branch forward only.

Branching backwards to simulate tail-recursion seems unobjectionable.

-- Richard

[Red Cent]

Two things I think need pointed out here.

1) As mentioned earlier in this thread, goto does NOT necessarily lead
to poor programming. If used with care, goto maybe a good choice, but
there is always an alternative. Whether it's a function call, a case
switch. All of these can be good alternatives BUT they can be abused
as well.

At least with a function call you know where and when that piece of
code will execute. But with labelled lines for goto purposes, it's
difficult to tell when it's being called, and when those lines just run
because of the order of execution.

2) Today's goto? #define!

I have often seen (and not just in purposely obfuscated code)
ridiculous define statements due to laziness. These problems often
disappear once people begin working together in a group, or review each
other's source code.

[Keith Thompson]

"John Bode" <jo*******@my-deja.com> writes:
[...]

IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.
2. Never branch into the middle of another control structure (if, for,
while, etc.)
3. Don't use goto if another control structure can do the same job.

Your rule 3 would eliminate goto statements altogether. There's a
well known theorem that any program using gotos can be transformed
into an equivalent program using only a particular small set of
structured control constructs (possibly with some extra flag
variables).

I'd amend your rule 3 to

3. Use goto only if it's (significantly) cleaner than any of the
equivalent alternatives.

and add:

4. If forced by circumstances to use a goto, curse under my breath
about the lack of a cleaner alternative in the language.

I can think of 3 cases where a goto is justified in C: an explicit
finite state machine, where a goto actually models something in the
problem domain (this could also be implemented as a switch statement
in a loop with an explicit state variable); error handling (due to the
lack of a decent exception handling mechanism); and breaking out of a
nested loop (due to C's regrettable lack of multi-level break).

The latter two could also be implemented by wrapping part of the code
in a small (perhaps inline) function, and using a return statement to
break out of it, but that's not necessarily an improvement. In
particular, it causes problems if an inner loop accesses variables
declared in outer scopes.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Marco]

M.B wrote:

So why goto is outlawed from civilized c programmers community.

several coding standard/style books

"Enough Rope to Shoot Yourself In the Foot"
" The Elements of C Programming Style"

suggest that a forward goto from nested loops is perfectly acceptable

they have examples similar to

while( condtion1 )
{
while( condtion2 )
{
if (something_bad)
goto leave;
...
}
}
leave:
...

I have used this in practice once or twice.

[Chuck F.]

Eric Sosman wrote:

Chuck F. wrote:

John Bode wrote:

... snip ...

IME, there are cases where a goto is useful, but they are
few and far between. I have no problems with gotos provided
some basic rules are followed:

1. Branch forward only.

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;
domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if
it could the goto is clearer.

Note that this can be trivially converted to a forward branch by
writing `outer: ;' just before the closing brace of the outer
loop. Note, too, that this conversion would be necessary, not
just possible, if the outer loop were a `for' or a `do...while'. >

I submit that coding a jump forward to execute a jump backward is
code obfuscation. As further evidence I cite the need for the
extraneous semicolon in this case.

For the do-while I agree, but with a for-loop I also claim that the
wrong loop is in use. I generally do not approve of using the for
as a generic loop construct when other constructs have the same effect.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Keith Thompson]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <11********************@o13g2000cwo.googlegroups.c om>,
John Bode <jo*******@my-deja.com> wrote:

1. Branch forward only.

Branching backwards to simulate tail-recursion seems unobjectionable.

C has perfectly good looping constructs.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[August Karlstrom]

Keith Thompson wrote:
[snip]

I can think of 3 cases where a goto is justified in C: an explicit
finite state machine, where a goto actually models something in the
problem domain (this could also be implemented as a switch statement
in a loop with an explicit state variable); error handling (due to the
lack of a decent exception handling mechanism); and breaking out of a
nested loop (due to C's regrettable lack of multi-level break).

The latter two could also be implemented by wrapping part of the code
in a small (perhaps inline) function, and using a return statement to
break out of it, but that's not necessarily an improvement. In
particular, it causes problems if an inner loop accesses variables
declared in outer scopes.

That's because C doesn't support local subroutines. If your language
does, it's a neat solution.
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

Branching backwards to simulate tail-recursion seems unobjectionable.

C has perfectly good looping constructs.

C has perfectly good recursion, but not all compilers implement it
well enough for some purposes.

I would usually rather overcome the deficiencies of compilers by using
a goto than by changing the algorithm.

-- Richard

[Emmanuel Delahaye]

M.B a écrit :

We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
A good advice, specially targetted to beginners.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
True enough.
So why goto is outlawed from civilized c programmers community.
I think goto is for experienced programmers who know the limits and
dangers induced by the use of this very sharp tool...
is there any technical inefficiency in that.

No. It's essentially a design issue. Noone like spaghetti code.

--
A+

Emmanuel Delahaye

[pemo]

"Richard Tobin" <ri*****@cogsci.ed.ac.uk> wrote in message
news:dp**********@pc-news.cogsci.ed.ac.uk...

C has perfectly good recursion, but not all compilers implement it
well enough for some purposes.

'but not all compilers implement it well enough for some purposes'

Please give an explanation

[I'm freaked out, and cannot sleep now]

[Emmanuel Delahaye]

Nils O. Selåsdal a écrit :

"Structured Programming with go to Statements"

This was my favorite game when I was programming in BASIC (the true one,
with "10 GOTO hell" etc.) and Assembly language... It drove by teacher
and supervisor crazy !

--
A+

Emmanuel Delahaye

[Malcolm]

"Keith Thompson" <ks***@mib.org> wrote

I can think of 3 cases where a goto is justified in C: an explicit
finite state machine, where a goto actually models something in the
problem domain (this could also be implemented as a switch statement
in a loop with an explicit state variable); error handling (due to the
lack of a decent exception handling mechanism); and breaking out of a
nested loop (due to C's regrettable lack of multi-level break).

I'd add a fourth - occasionally scratch code to examine program flow might
need a goto
(You can implement the debug control structure with loops, but that might
entail messy brackets that obscure the real non-debug control structure.)

[Richard Tobin]

In article <dp**********@news.ox.ac.uk>, pemo <us***********@gmail.com> wrote:

C has perfectly good recursion, but not all compilers implement it
well enough for some purposes.

'but not all compilers implement it well enough for some purposes'

Please give an explanation

Consider a function of the form

some_type foo(some args)
{
...
if(some condition)
return foo(some other args);
...
}

(obviously the recursive call has to be in a conditional). The
compiler does not need to create a new stack frame for the recursive
call, since it will never return to the current frame (except to
return immediately). This is called "tail-recursion optimization",
and if you can rely on it then you can use recursion of this sort even
in cases where the depth of recursion would be very deep, and might
otherwise run out of memory.

Some C compilers do this optimization in some cases (gcc for example)
but it is not guaranteed by the standard. Some other languages
(notably Scheme) do guarantee it.

-- Richard

[Christian Bau]

In article <11**********************@g14g2000cwa.googlegroups .com>,
"Red Cent" <tr**********@sbcglobal.net> wrote:

Two things I think need pointed out here.

1) As mentioned earlier in this thread, goto does NOT necessarily lead
to poor programming. If used with care, goto maybe a good choice, but
there is always an alternative. Whether it's a function call, a case
switch. All of these can be good alternatives BUT they can be abused
as well.

All these anti-goto tirades come from a time in ancient history, where
widespread programming language had nothing but goto to implement simple
control flow. For example, in Fortran 66 there was not even a simple if
/ else / endif available. The forced use of goto because alternatives
were not available did certainly make programs less readable.

If anyone is studying C today, it is hard to imagine why they would use
goto in a substantial number of places, unless there is an especially
warped mind in place. If/else, loops, break and continue are just so
much easier to use in most cases.

[Peter Nilsson]

Marco wrote:

M.B wrote:

So why goto is outlawed from civilized c programmers community.

several coding standard/style books

"Enough Rope to Shoot Yourself In the Foot"
" The Elements of C Programming Style"

suggest that a forward goto from nested loops is perfectly acceptable

they have examples similar to

while( condtion1 )
{
while( condtion2 )
{
if (something_bad)
goto leave;
...
}
}
leave:
...

Indeed. The only caveat here is that labels like 'leave' must label
actual statements.
If there isn't one, e.g. if you're jumping into the end of a block, you
should create
an empty statement...

void foo(void)
{
while (cond1)
{
while (cond2)
{
while (cond3)
{
if (cond4) goto continue_while_1;
...
}
}
continue_while_1:
; /* ; (or equivalent) needed */
}
}

--
Peter

[Richard Bos]

Thad Smith <Th*******@acm.org> wrote:

M.B wrote:

So why goto is outlawed from civilized c programmers community.

About 1968 or so Edsger Dijkstra wrote an article, published as a Letter
to the Editor in the ACM Communications magazine, titled Go To
Considered Harmful.

Actually, he didn't. When he wrote it, it was titled differently. Editor
of the ACM Considered Harmful.

Richard

[Michael Wojcik]

In article <ch*********************************@slb-newsm1.svr.pol.co.uk>, Christian Bau <ch***********@cbau.freeserve.co.uk> writes:

If anyone is studying C today, it is hard to imagine why they would use
goto in a substantial number of places, unless there is an especially
warped mind in place.

Is it really? A number of regulars here seem to have imagined it,
but perhaps we are particularly imaginative, or particularly warped.

I have a large code base where at least one goto appears in the
majority of the functions. They're all for handling errors with a
single point of return, but they definitely occupy "a substantial
number of places" in the code.

Now, that style may not be to your preference, but I submit that it's
hardly difficult to imagine why someone might employ it.

--
Michael Wojcik mi************@microfocus.com

When [Columbus] landed on America it was more like an evasion than a
discovery. -- Matt Walsh

[Herbert Rosenau]

On Wed, 4 Jan 2006 15:51:08 UTC, "John Bode" <jo*******@my-deja.com>
wrote:

IME, there are cases where a goto is useful, but they are few and far
between.
Please name one! Only one. In 25 years of programming in C i have
never found a single one. I've written small, middle and really big
applications, I've written drivers, whole OSes for realtime
environments but have never found a reason to write goto.
I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.
2. Never branch into the middle of another control structure (if, for,
while, etc.)
3. Don't use goto if another control structure can do the same job.

is there any technical inefficiency in that.

ISTR some verbiage in H&S that the presence of a goto can hinder some
compiler optimizations.

In all of the 25 years I had to write code in highest security and
time critical environments whereasd any fault would have cost human
live.

There were only 3 rules to follow:
1. readability
not necessary for beginners in C but experts
2. security
avoid any obsurity
3. maintenacaiblity

All 3 rules contains avoiding goto by design, not code. Giving the
code a chance for goto is violating at least one of the 3 rules,
therefore a cause to redesign the sequence.
--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Wed, 4 Jan 2006 17:06:25 UTC, "Chuck F. " <cb********@yahoo.com>
wrote:

John Bode wrote:

... snip ...

IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;
Very bad design!
domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if it
could the goto is clearer.

Redesign the whole block and you will avoid the label and the goto
statement implicite.

2. Never branch into the middle of another control structure
(if, for, while, etc.)

See the Knuth paper (reference from me upthread) for a
counterexample. s/Never/Almost never/

3. Don't use goto if another control structure can do the same
job.

This one I can accept.

A good design will evacuate details of "how to do" into a deeper level
to hide it from "what is to do". That will increase the readability
and security by hiding details while increasing the maintenceability
and decreasing the time needed to debug the functionality.

isdoable = init();
while (isdoable && primary())
while(!!(isdoable = secondary())
if (!realwork()) {
if (errorhandling())
isdoable = FALSE;
break;
}
cleanup();
return;

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Keith Thompson]

"Herbert Rosenau" <os****@pc-rosenau.de> writes:

On Wed, 4 Jan 2006 15:51:08 UTC, "John Bode" <jo*******@my-deja.com>
wrote:

IME, there are cases where a goto is useful, but they are few and far
between.

Please name one! Only one. In 25 years of programming in C i have
never found a single one. I've written small, middle and really big
applications, I've written drivers, whole OSes for realtime
environments but have never found a reason to write goto.

A goto statement is never necessary in a language that has a minimal
set of structured control constructs (there's a theorem to that
effect), but it *can* be useful at times.

For example:

void foo(void)
{
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

foo = init_foo_type(); /* returns NULL on error */
if (foo == NULL) goto ERROR;

bar = init_bar_type();
if (bar == NULL) goto ERROR;

baz = init_baz_type();
if (baz == NULL) goto ERROR;

/*
* A bunch of code that uses foo, bar, and baz.
*/

ERROR:
if (baz != NULL) cleanup_baz_type(baz);
if (bar != NULL) cleanup_bar_type(bar);
if (foo != NULL) cleanup_foo_type(foo);
}

Of course it could be restructured. The most obvious way to do so is
to use nested if statements, with the nesting level becoming deeper as
the number of initializations increases. Another approach is to
replace each "goto ERROR;" with a return statement; the second and
third would have to be preceded by cleanup calls.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.org> wrote:

void foo(void)
{
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

foo = init_foo_type(); /* returns NULL on error */
if (foo == NULL) goto ERROR;

bar = init_bar_type();
if (bar == NULL) goto ERROR;

baz = init_baz_type();
if (baz == NULL) goto ERROR;

/*
* A bunch of code that uses foo, bar, and baz.
*/

ERROR:
if (baz != NULL) cleanup_baz_type(baz);
if (bar != NULL) cleanup_bar_type(bar);
if (foo != NULL) cleanup_foo_type(foo);
} Of course it could be restructured. The most obvious way to do so is
to use nested if statements, with the nesting level becoming deeper as
the number of initializations increases.
Which (contrary to Herbert Rosenau's assertion) would make the code
less readable, at least to me.
Another approach is to
replace each "goto ERROR;" with a return statement; the second and
third would have to be preceded by cleanup calls.

Which would make maintenance harder and increase the risk of errors,
since the cleanup code would have to be maintained in both places.

A rigid rule against gotos is like the rule against split infinitives:
a fetish (cf Fowler's Modern English Usage). In both cases the
solution is not a rule but good taste and experience.

-- Richard

[Skarmander]

Herbert Rosenau wrote:
<snip>

A good design will evacuate details of "how to do" into a deeper level
to hide it from "what is to do". That will increase the readability
and security by hiding details while increasing the maintenceability
and decreasing the time needed to debug the functionality.

isdoable = init();
while (isdoable && primary())
while(!!(isdoable = secondary())
if (!realwork()) {
if (errorhandling())
isdoable = FALSE;
break;
}
cleanup();
return;

Hurrah, we have avoided the evil goto. In the process, we demonstrate some
other readability-decreasing features: !! to "convert" to boolean, combining
assignment and test, omitting braces around multiply-nested statements.

This is a perfect example of when a labeled break would come in handy. C
does not have them; a goto would do.

if (!init()) goto do_cleanup;
while (primary()) {
while (secondary()) {
if (!realwork()) {
if (errorhandling()) goto do_cleanup;
break;
}
}
}
do_cleanup:
cleanup();
return;

Evacuating details notwithstanding, I can't come up with arguments as to why
a version that uses a control variable should be better design than one
without it.

Holy wars have been waged on this topic for a very long time now; although
one is free to prefer one style over another, it is wise to consider the
possibility that there are not altogether many rational arguments in favor
or against either side.

This example in particular boils down to whether you think goto is bad or
not. You can waffle about design all you want, but this is code at the most
basic level. Same nesting, same functions, almost the same line count --
what you prefer is really a matter of taste.

S.

[Chuck F.]

Herbert Rosenau wrote:

"Chuck F. " <cb********@yahoo.com> wrote:
.... snip objection to backward goto ...

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;

Very bad design!

domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if
it could the goto is clearer.

Redesign the whole block and you will avoid the label and the
goto statement implicite.

Oh - and how would you redesign it, bearing in mind that condition3
is in the nature of a local abort and that the emphasis is on doing
things? The idea is clarity, and I suspect whatever you are
thinking of will tend to obfuscate.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Richard Heathfield]

Chuck F. said:

Oh - and how would you redesign it, bearing in mind that condition3
is in the nature of a local abort and that the emphasis is on doing
things? The idea is clarity, and I suspect whatever you are
thinking of will tend to obfuscate.

I'd start off by choosing much better names.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Herbert Rosenau]

On Fri, 6 Jan 2006 20:48:16 UTC, Keith Thompson <ks***@mib.org> wrote:

A goto statement is never necessary in a language that has a minimal
set of structured control constructs (there's a theorem to that
effect), but it *can* be useful at times.

For example:
Crappy design:
void foo(void)
{
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

foo = init_foo_type(); /* returns NULL on error */
if (foo == NULL) goto ERROR;

bar = init_bar_type();
if (bar == NULL) goto ERROR;

baz = init_baz_type();
if (baz == NULL) goto ERROR;

/*
* A bunch of code that uses foo, bar, and baz.
*/

ERROR:
if (baz != NULL) cleanup_baz_type(baz);
if (bar != NULL) cleanup_bar_type(bar);
if (foo != NULL) cleanup_foo_type(foo);
}
The same without goto:

if ((foo = init_foo_type())
&& (bar = init_bar_type())
&& (baz = init_baz_type())
) {
/* work */
}
cleanup_baz_type(baz);
cle......

or avoiding the big if and breaking the whole work down into different
levels, hiding too much details but giving better overview of the real
work:

static int init_types(int **foo, int **bar, int **baz) {
return (*foo = init_foo_type())
&& (*bar = init_bar_type())
&& (*baz = init_baz_type());
}

static void cleanup_types(.... like init_types but cleanup.......
:
:
:
void foo(void) {
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

if (init_types(&foo, &bar, &baz)) {
do_work(....);
}
cleanup_types(&foo, &bar, &baz);
}

I would prefere the second choice when runtime is not really critical
because it makes anything more maintenanceable and more readable.
Of course it could be restructured. The most obvious way to do so is
to use nested if statements, with the nesting level becoming deeper as
the number of initializations increases. Another approach is to
replace each "goto ERROR;" with a return statement; the second and
third would have to be preceded by cleanup calls.

I would reduce the number of if statements and increasing the
readability, and the time testing is needed. When init is tested well
it can be ignored easy during forthgoing debug becaus it is known as
ready for GA. The same is for the real work......

I like to hide so much details as possible because it is after 3 years
untouched sources more easy to extend or even change the functionality
when details are hidden until there is a real need to know about them.
So looking at WHAT is going on and looking on HOW is it done only when
there is a need for makes anything much easier to understund.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Fri, 6 Jan 2006 21:02:00 UTC, "Chuck F. " <cb********@yahoo.com>
wrote:

Herbert Rosenau wrote:

"Chuck F. " <cb********@yahoo.com> wrote:

... snip objection to backward goto ...

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;

Very bad design!

domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even if
it could the goto is clearer.

Redesign the whole block and you will avoid the label and the
goto statement implicite.

Oh - and how would you redesign it, bearing in mind that condition3
is in the nature of a local abort and that the emphasis is on doing
things? The idea is clarity, and I suspect whatever you are
thinking of will tend to obfuscate.

Break down the whole complicate thing in levels:
level description
1 show up WHAT is to do
when needed recurse level 1
2 how is it done
when needed recurse level 1 until
there is only one single step to do
or the number of steps is very short
and unconditional.

This can always be done by creating functions hiding details of what
is to do respective how is the detail done. This can (but must not)
reduce a number of if, for, while statements but will avoid any goto
by design.

Break down the whole program in a sequence of single steps. Code each
single step as own function whereas each function itself will
break down the whole function in a sequence wheras.....
...... until a single function fits on a screen size and has not more
direct nested control statemens as 3 or 4.

You would easy learn by that that C has some levels of visibility of
variables and functions and you'll learn to use that well.

After you has learned programming in C you would have to learn
programming using C. Then you would be ready to use C instead of
basic, FORTRAN or cobol or pure assembly and forget about goto and its
existence because you'll never see a need for.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Herbert Rosenau]

On Fri, 6 Jan 2006 22:11:10 UTC, Skarmander <in*****@dontmailme.com>
wrote:

Herbert Rosenau wrote:
<snip>

A good design will evacuate details of "how to do" into a deeper level
to hide it from "what is to do". That will increase the readability
and security by hiding details while increasing the maintenceability
and decreasing the time needed to debug the functionality.

isdoable = init();
while (isdoable && primary())
while(!!(isdoable = secondary())
if (!realwork()) {
if (errorhandling())
isdoable = FALSE;
break;
}
cleanup();
return;

Hurrah, we have avoided the evil goto. In the process, we demonstrate some
other readability-decreasing features: !! to "convert" to boolean, combining
assignment and test, omitting braces around multiply-nested statements.

This is a perfect example of when a labeled break would come in handy. C
does not have them; a goto would do.

if (!init()) goto do_cleanup;
while (primary()) {
while (secondary()) {
if (!realwork()) {
if (errorhandling()) goto do_cleanup;
break;
}
}
}
do_cleanup:
cleanup();
return;

Evacuating details notwithstanding, I can't come up with arguments as to why
a version that uses a control variable should be better design than one
without it.

Holy wars have been waged on this topic for a very long time now; although
one is free to prefer one style over another, it is wise to consider the
possibility that there are not altogether many rational arguments in favor
or against either side.

This example in particular boils down to whether you think goto is bad or
not. You can waffle about design all you want, but this is code at the most
basic level. Same nesting, same functions, almost the same line count --
what you prefer is really a matter of taste.

S.

You're right that my example is not the best. But in the short time I
found nothing that I were able to use to make from a nonsense a real
good design. For a blind hack of code that makes as such no sense it
was the best to show up other code without sense but avoiding goto.

Real design starts at much higher level and will avoid some constructs
before there is a chance to write a single statement.

!! is a possibility to save typing (and mistyping, e.g. like = instead
of ==). True, yes I do never take consideration of beginners in
learning C because one has to learn the language by using it.

Yes, I don't like empty lines whenever there is a chance to avoid one,
except an empty line can stand for self declaring documentation saying
there starts a new logical block of execution. Yes, I avoid {}
whenever possible because that gives up to 2 more lines on the same
screen page.
But for that my editor knows how to indent right and it will prove the
matching of braces every time I ask it for. True, this all is at least
a question of style but avoiding goto and longjump is never. You would
know that when you have written one singe project that has not only to
be failsave but has to save human live in any condition and not only
some money.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Keith Thompson]

"Herbert Rosenau" <os****@pc-rosenau.de> writes:

On Fri, 6 Jan 2006 20:48:16 UTC, Keith Thompson <ks***@mib.org> wrote:

A goto statement is never necessary in a language that has a minimal
set of structured control constructs (there's a theorem to that
effect), but it *can* be useful at times.

For example:
Crappy design:

void foo(void)
{
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

foo = init_foo_type(); /* returns NULL on error */
if (foo == NULL) goto ERROR;

bar = init_bar_type();
if (bar == NULL) goto ERROR;

baz = init_baz_type();
if (baz == NULL) goto ERROR;

/*
* A bunch of code that uses foo, bar, and baz.
*/

ERROR:
if (baz != NULL) cleanup_baz_type(baz);
if (bar != NULL) cleanup_bar_type(bar);
if (foo != NULL) cleanup_foo_type(foo);
}

The same without goto:

if ((foo = init_foo_type())
&& (bar = init_bar_type())
&& (baz = init_baz_type())
) {
/* work */
}
cleanup_baz_type(baz);
cle......

That assumes each initialization can be done in a single expression
statement. That happens to be true in my example, but it needn't be,
and your transformation won't work for more complex cases. Sure, you
could write your own init_*() functions to guarantee that each piece
of initialization can be done with a single function call, but that
just moves the complexity somewhere else (which could be a good
thing).

Also, you're calling the cleanup_*() functions without checking
whether their arguments are non-NULL.
or avoiding the big if and breaking the whole work down into different
levels, hiding too much details but giving better overview of the real
work:

static int init_types(int **foo, int **bar, int **baz) {
return (*foo = init_foo_type())
&& (*bar = init_bar_type())
&& (*baz = init_baz_type());
}

static void cleanup_types(.... like init_types but cleanup.......
:
:
:
void foo(void) {
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

if (init_types(&foo, &bar, &baz)) {
do_work(....);
}
cleanup_types(&foo, &bar, &baz);
}

I would prefere the second choice when runtime is not really critical
because it makes anything more maintenanceable and more readable.

Now you're creating new functions that are called only once. That's
not *necessarily* a bad idea, but it sometimes can lead to what you
might call structured spaghetti.

[snip]

I rarely, if ever, use gotos myself, and if I were writing the above
code I'd probably try to find a way to avoid them. Indiscriminate use
of gotos is undoubtedly dangerous. Careful use of gotos *can* be ok,
particularly if they're used only to work around a missing language
feature such as exception handling or multi-level break. And of
course it's not the least bit difficult to write horrendously bad code
without using a single goto.

Digression:

We're able to avoid gotos for the most part because the language gives
us higher level control structures. This is less true for data
structures than for control structures. A goto in a control structure
is analagous to a pointer as a data structure. In both cases, the
programmer is responsible for keeping everything consistent, and
failure to do so can be disastrous. Using explicit gotos to implement
a higher-level control structure is frowned upon; using explicit
pointers to implement a higher-level data structure (such as a linked
list or binary tree) is standard practice.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Skarmander]

Herbert Rosenau wrote:

On Fri, 6 Jan 2006 22:11:10 UTC, Skarmander <in*****@dontmailme.com>
wrote:

Herbert Rosenau wrote:
<snip>

A good design will evacuate details of "how to do" into a deeper level
to hide it from "what is to do". That will increase the readability
and security by hiding details while increasing the maintenceability
and decreasing the time needed to debug the functionality.

isdoable = init();
while (isdoable && primary())
while(!!(isdoable = secondary())
if (!realwork()) {
if (errorhandling())
isdoable = FALSE;
break;
}
cleanup();
return;

Hurrah, we have avoided the evil goto. In the process, we demonstrate some
other readability-decreasing features: !! to "convert" to boolean, combining
assignment and test, omitting braces around multiply-nested statements.

This is a perfect example of when a labeled break would come in handy. C
does not have them; a goto would do.

if (!init()) goto do_cleanup;
while (primary()) {
while (secondary()) {
if (!realwork()) {
if (errorhandling()) goto do_cleanup;
break;
}
}
}
do_cleanup:
cleanup();
return;

Evacuating details notwithstanding, I can't come up with arguments as to why
a version that uses a control variable should be better design than one
without it.

Holy wars have been waged on this topic for a very long time now; although
one is free to prefer one style over another, it is wise to consider the
possibility that there are not altogether many rational arguments in favor
or against either side.

This example in particular boils down to whether you think goto is bad or
not. You can waffle about design all you want, but this is code at the most
basic level. Same nesting, same functions, almost the same line count --
what you prefer is really a matter of taste.

S.

You're right that my example is not the best. But in the short time I
found nothing that I were able to use to make from a nonsense a real
good design. For a blind hack of code that makes as such no sense it
was the best to show up other code without sense but avoiding goto.

Real design starts at much higher level and will avoid some constructs
before there is a chance to write a single statement.

I don't doubt it's possible to call some approach to design "real design"
and coincidentally have this approach avoid all cases where goto could come
in handy.

Not that it's easy, mind you. If high-level "real design" impacts how code
is written at the lowest level, there is something suspicious about it.
!! is a possibility to save typing (and mistyping, e.g. like = instead
of ==). True, yes I do never take consideration of beginners in
learning C because one has to learn the language by using it.
I'm not a beginner and I do know perfectly what !! means. Knowing what it
means and wanting to use it are two different things (as you know, of
course, through avoiding goto. :-)

The = vs. == thing is indeed another wart of C best avoided, but this at
least is something even the beginners quickly grow wise to. There's not
enough code out there using the !! trick to make it as readable. You can
parse it, but it takes time. How much time code takes to *type* is all but
insignificant (I'm sure managers will tell you otherwise, but most of those
managers couldn't program if their lives depended on it, let alone judge
coding techniques.)
Yes, I don't like empty lines whenever there is a chance to avoid one,
except an empty line can stand for self declaring documentation saying
there starts a new logical block of execution. Yes, I avoid {}
whenever possible because that gives up to 2 more lines on the same
screen page.
Well, this is another one of those holy war things we'd best not touch and
chalk up to personal preference. Those things probably make a difference one
way or another, but not enough to quibble about.
But for that my editor knows how to indent right and it will prove the
matching of braces every time I ask it for. True, this all is at least
a question of style but avoiding goto and longjump is never. You would
know that when you have written one singe project that has not only to
be failsave but has to save human live in any condition and not only
some money.

Ooh, here you go making assumptions, and we all know how dangerous that is.
You're in luck, though: I'm not going to tell you I wrote the control
program for a nuclear reactor or an X-ray scanner and used goto and
longjmp() to good effect. I wouldn't turn this into a "my application field
is more sensitive to failure than yours" debate, though; this tends to be
unproductive. Some applications that saved "some money" arguably had plenty
of impact on the quality and possibly quantity of human life, too.

Even without the benefit of this no doubt insightful experience, your
assertion is mere bluster, since you're not going to prove that the use of
goto was what condemned such a project in the past. It is an appeal to
emotion that boils down to "goto makes your project bad, and in your really
important project it's a liability".

What next? "goto kills"? I'm sure it has. So have floating-point
calculations and exceptions (in other languages). In all of these cases it
is dubious to propose the features themselves were wrong. Misapplied, yes.
Easy to misapply, certainly. Never appropriate, not necessarily.

What is true is that goto (and longjmp() even more so) are hard to use
*appropriately*. This is why goto should be avoided: if you don't know why
you're using goto and not some other control structure, you're not using it
right and should stop. Write something you can control. Better, write
something that is obvious not just to you, but to anyone of slightly less
capacity than yourself. (It is useless to write code for programmers vastly
worse than yourself, since they cannot modify what they do not understand
anyway; it is likewise useless to try and be smarter than you actually are
on a bad day, which is a much more common failing.)

Programmers do not how to use goto properly either because they've *never*
been told not to use it, or because they've *always* been told not to use
it. Yes, you can shoot yourself in the foot with goto, no question about it.
Then again, you can shoot yourself in the foot with a lot of things in C.
None of this can serve as a blanket condemnation. The pitfalls of goto are
well known, and all the arguments for and against are, too. Those who are
not familiar with them should stick with "never use goto", since it makes
the world a better place for all of us. I would be the last one to advocate
changing this happy status quo.

goto has its uses. Anyone who denies this is calling Donald Knuth wrong.
Unrestricted use of goto is harmful. Anyone who denies this is calling
Edsger Dijkstra wrong. I wouldn't take either of those men on lightly
without some very good arguments, because they usually have them handy.

I'd like to close this debate with an important remark: I can count the
number of times I've used goto in applications on the fingers of one hand,
quite unlike the number of programs I've written, for which no appendages
suffice (they would if I counted in binary, though). The count for longjmp()
stands at zero.

Why? Because goto was not the appropriate solution to the problem in almost
every case. In those cases where I used it, it was. Equivalent code not
using goto of course existed, but it was less elegant and less readable.
There aren't many legitimate uses of goto -- but where they are, it is
fanaticalism to say that they, too, should be abolished because they raise
the spectre of wrongful application. It's likewise silly to say "but you can
do that without goto". Of course. Then I can say "but you can do that
without while". It doesn't really advance things.

S.

[August Karlstrom]

Herbert Rosenau wrote:
[snip]

True, this all is at least
a question of style but avoiding goto and longjump is never. You would
know that when you have written one singe project that has not only to
be failsave but has to save human live in any condition and not only
some money.

I doubt that C is the right tool for safety critical programs. I think
the general problem with C is not the language itself, but that it's
used outside the system programming area.

Here is a classical quote about goto:

"As for GOTO, I have this to say:

The apprentice uses it without thinking.
The journeyman avoids it without thinking.
The master uses it thoughtfully."
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.

[Chuck F.]

Herbert Rosenau wrote:

"Chuck F. " <cb********@yahoo.com> wrote:

Herbert Rosenau wrote:

"Chuck F. " <cb********@yahoo.com> wrote:

... snip objection to backward goto ...

Counterexample:

preliminarysetup();
outer: while (condition1) {
dosumthing();
while (condition2) {
dosumthingelse();
if (condition3) goto outer;

Very bad design!

domore();
}
dostillmore();
}

The goto cannot be replaced by break or continue, and even
if it could the goto is clearer.

Redesign the whole block and you will avoid the label and
the goto statement implicite.

Oh - and how would you redesign it, bearing in mind that
condition3 is in the nature of a local abort and that the
emphasis is on doing things? The idea is clarity, and I
suspect whatever you are thinking of will tend to obfuscate.

Break down the whole complicate thing in levels:
level description
1 show up WHAT is to do
when needed recurse level 1
2 how is it done
when needed recurse level 1 until
there is only one single step to do
or the number of steps is very short
and unconditional.

This can always be done by creating functions hiding details of
what is to do respective how is the detail done. This can (but
must not) reduce a number of if, for, while statements but will
avoid any goto by design.

Break down the whole program in a sequence of single steps. Code
each single step as own function whereas each function itself
will break down the whole function in a sequence wheras.....
...... until a single function fits on a screen size and has not
more direct nested control statemens as 3 or 4.

You would easy learn by that that C has some levels of
visibility of variables and functions and you'll learn to use
that well.

After you has learned programming in C you would have to learn
programming using C. Then you would be ready to use C instead of
basic, FORTRAN or cobol or pure assembly and forget about goto
and its existence because you'll never see a need for.

I don't think this self-aggrandizement deserves a reply. I am
quoting the whole thing to expose the foolishness.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

[Richard Heathfield]

August Karlstrom said:

Here is a classical quote about goto:

"As for GOTO, I have this to say:

The apprentice uses it without thinking.
The journeyman avoids it without thinking.
The master uses it thoughtfully."

Unfortunately, there are way too many apprentices who think they are
masters.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Herbert Rosenau]

On Sat, 7 Jan 2006 22:20:27 UTC, Keith Thompson <ks***@mib.org> wrote:

"Herbert Rosenau" <os****@pc-rosenau.de> writes:

On Fri, 6 Jan 2006 20:48:16 UTC, Keith Thompson <ks***@mib.org> wrote: The same without goto:

if ((foo = init_foo_type())
&& (bar = init_bar_type())
&& (baz = init_baz_type())
) {
/* work */
}
cleanup_baz_type(baz);
cle......
That assumes each initialization can be done in a single expression
statement. That happens to be true in my example, but it needn't be,
and your transformation won't work for more complex cases.

Sure, the transformation was done on your exampel, not on a more
complex one. A more complex one had gotten another transformation
because it had needed another design.

Sure, you could write your own init_*() functions to guarantee that each piece
of initialization can be done with a single function call, but that
just moves the complexity somewhere else (which could be a good
thing).
That is why I say "make a right design and some problems going away
alone.
Also, you're calling the cleanup_*() functions without checking
whether their arguments are non-NULL.
Hey, it is the job of a cleanup that can receive errornous data to
check it. When the design says it has to handle null pointers it must
do so. If it were impossible to receive ones it would not.

or avoiding the big if and breaking the whole work down into different
levels, hiding too much details but giving better overview of the real
work:

static int init_types(int **foo, int **bar, int **baz) {
return (*foo = init_foo_type())
&& (*bar = init_bar_type())
&& (*baz = init_baz_type());
}

static void cleanup_types(.... like init_types but cleanup.......
:
:
:
void foo(void) {
foo_type *foo = NULL;
bar_type *bar = NULL;
baz_type *baz = NULL;

if (init_types(&foo, &bar, &baz)) {
do_work(....);
}
cleanup_types(&foo, &bar, &baz);
}

I would prefere the second choice when runtime is not really critical
because it makes anything more maintenanceable and more readable.

Now you're creating new functions that are called only once. That's
not *necessarily* a bad idea, but it sometimes can lead to what you
might call structured spaghetti.

No, it can not because C knows of different storage classes and one
should know how to use them even on functions. The design of a
translation unit is design that can even be done before the first
statement gets written.

One time functions an excellent method to refine a job from an
overview to the last detail. Each one time function will clearly be on
storage class static to document that it is never used outside this
translation unit. So until you have a need to look into the
implementation details you can surely ignore it.

My style guide is to organise each translation unit in logical blocks
- #define and #ifdef as needed to modify #included files
- #include external definitions and declarations as needed
commonly known as header files
- defining data used by other translation units but
associated to this translation unit
- defining data and macros needed on file scope but
only in this translation unit
- declaring one time functions
- declaring other static functions
- defining local functions
- defining external callable functions
(declarations are in #included header files,
giving the compiler a chance to check prototypes
agaist the definitions)
- for each function: the same as for the whole translation unit.

[snip]

I rarely, if ever, use gotos myself, and if I were writing the above
code I'd probably try to find a way to avoid them. Indiscriminate use
of gotos is undoubtedly dangerous. Careful use of gotos *can* be ok,
particularly if they're used only to work around a missing language
feature such as exception handling or multi-level break. And of
course it's not the least bit difficult to write horrendously bad code
without using a single goto.
As sayed I have in 25 years programming C never found a cause to write
goto. I had never missed exceptions as in C++ (maybe because my
history is another 10 years of programming in assembly on highly
different mashines before I got to learn to be a C programmer).

Yes I had missed sometimes labled break, but not really as on all
places it were useful as such the complexitiy of the whole blox was
high enough to redesign as ((a copule of) one time) functions to get
off the complexity of the problem.
Digression:

We're able to avoid gotos for the most part because the language gives
us higher level control structures. This is less true for data
structures than for control structures. A goto in a control structure
is analagous to a pointer as a data structure.
No. An own function for a block of code is the same as a struct for
data. Encapsulate code to hide complexity makes more sense as it
increases the readability which increases the maintenceabiltity.

In both cases, the programmer is responsible for keeping everything consistent, and
failure to do so can be disastrous. Using explicit gotos to implement
a higher-level control structure is frowned upon;
No, not really. That decreases only the readability and avoids
manintenanceability. It is hard to find a goto and the cause for when
you have to maintenance code you've not written or you've not touched
the sources for years.

using explicit pointers to implement a higher-level data structure (such as a linked
list or binary tree) is standard practice.

Yes, but even there I've seen the wrong type of linked list for the
job it had to hold for. It is easy to make the wrong desin in both
data and code. Wheras it is sometimes not so easy to rework the design
before coding starts and often nearly impossible thereafter based on
time and cost needed for.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Keith Thompson]

"Herbert Rosenau" <os****@pc-rosenau.de> writes:

On Sat, 7 Jan 2006 22:20:27 UTC, Keith Thompson <ks***@mib.org> wrote: [...]

Digression:

We're able to avoid gotos for the most part because the language gives
us higher level control structures. This is less true for data
structures than for control structures. A goto in a control structure
is analagous to a pointer as a data structure.

No. An own function for a block of code is the same as a struct for
data. Encapsulate code to hide complexity makes more sense as it
increases the readability which increases the maintenceabiltity.

Except that the internals of a struct are visible to its callers; the
equivalent would be allowing the caller of a function to have access
to every individual statement within the function. The equivalent of
a function would be a structure whose members are hidden.

In both cases, the
programmer is responsible for keeping everything consistent, and
failure to do so can be disastrous. Using explicit gotos to implement
a higher-level control structure is frowned upon;

No, not really. That decreases only the readability and avoids
manintenanceability. It is hard to find a goto and the cause for when
you have to maintenance code you've not written or you've not touched
the sources for years.

Where does the "No, not really" comes from? I don't see how you're
disagreeing with what I wrote here.

(BTW, the words are "maintainability" and "maintain", not
"manintenanceability" and "maintenance".)
using explicit

pointers to implement a higher-level data structure (such as a linked
list or binary tree) is standard practice.

Yes, but even there I've seen the wrong type of linked list for the
job it had to hold for. It is easy to make the wrong desin in both
data and code. Wheras it is sometimes not so easy to rework the design
before coding starts and often nearly impossible thereafter based on
time and cost needed for.

Agreed. (And of course the analogy between control structures and
data structures isn't absolute, but there are some interesting things
to learn from looking at things that way.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[tmp123]

August Karlstrom wrote:

I doubt that C is the right tool for safety critical programs. I think
the general problem with C is not the language itself, but that it's
used outside the system programming area.

Sorry, could you expand a few more this part?.

Thanks.

[Chris Hills]

In article <11*********************@g43g2000cwa.googlegroups. com>,
tmp123 <tm****@menta.net> writes

Richard Heathfield wrote:

tmp123 said:

> Thus, I suggest you to review the usage of "try"/"catch"/... (forget my
> sugestion if you know them).

They don't exist in C.

Yes, you have reason, I forget to remark it (a good reason to start in
C++).

However, I'm sure you known it is posible a workaround with a few
macros like:

#define TRY if(...(setjmp(...
#define CATCH else
#define RAISE logjmp(...

Kind regards.

Most standards that ban got also ban setjmp and logjmp

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[websnarf]

John Bode wrote:

M.B wrote:

Need some of your opinion on an oft beaten track
We have an option of using "goto" in C language, but most testbooks
(even K&R) advice against use of it.
My personal experience was that goto sometimes makes program some more
cleaner and easy to understand and also quite useful (in error handling
cases).
So why goto is outlawed from civilized c programmers community.
IME, there are cases where a goto is useful, but they are few and far
between. I have no problems with gotos provided some basic rules are
followed:

1. Branch forward only.

This is nonsense.
2. Never branch into the middle of another control structure (if, for,
while, etc.)
There are cases where this leads to a performance improvement to do so.
3. Don't use goto if another control structure can do the same job.
You can always use another control structure -- the question is whether
or not doing so makes the code more complicated or slower.

I personally follow only one rule regarding goto: avoid using it unless
using it leads to either clearer code or faster (executing) code. This
rule alone is sufficient to make the use of goto fairly uncommon in my
code to the point of "spaghetti code" never being an issue. (If
there's one exception it would have to be parsers -- but in those cases
even the cleanest control structures don't actually lead to a clearer
representation of the parser.)

The typical cases where goto is useful: 1) when escaping from more than
one level of loop control, 2) when you have more than one "clean up and
return" code fragment that can be reached from even more scenarios
(typically "clean up and return error" versus "clean up and return
sucess".) 3) Any state machine (switch often doesn't make things
clearer, and can make things horrendously slower.) 4) Starting a
performance critical tight loop from the middle.
ISTR some verbiage in H&S that the presence of a goto can hinder some
compiler optimizations.

There may be some weak older generation compilers for which that is
true. However, most modern compilers actually internally transform all
control structures to "if ... goto" anyways.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/