when GOTO makes sense.

[Debashish Chakravarty]

K&R pg.66 describes two situations when using goto makes sense. Has
anyone here come across situations where using goto provided the most
elegant solution.

--
http://www.kashmiri-pandit.org/atrocities/index.html

[Ed Morton]

On 12/7/2003 4:00 PM, Barbrawl McBribe wrote:

Debashish Chakravarty <de********@yah oo.com> wrote in message news:<3F******* *******@yahoo.c om>...

K&R pg.66 describes two situations when using goto makes sense. Has
anyone here come across situations where using goto provided the most
elegant solution.

Breaking out of complex loops?? That's the O'Reilly example at any rate.

So, imagine you have to maintain some code. You're new to the domain, trying to
make sense of 1000 lines of code in a hurry to fix a problem that a customer is
threatening to apply penalty clauses for. You're knee deep in, say, a complex
nested loop and suddenly, after a test on a couple of variables and a function
return code, you find a line that says "goto cleanup;". Can you say
"Aaaarrgggghhh! !!!"? Wouldn't a nice little variable that describes the
condition under which you're exiting the loop be a more pleasant discovery?

Ed.

[CBFalconer]

Dan Pop wrote:

CBFalconer <cb********@yah oo.com> writes:
.... snip ...

However I have found no /reasonable/ way to regression test my
nmalloc package, since the pointers it returns depend on the
state of the rest of the machine.

If you have problems testing a malloc package, it's most likely
due to its extremely bad design.

I think it is high time for you to take Richards refresher course
in Reading for Comprehension, after which you can consider the
"/reasonable/" and "regression test" above, and the implication
(from the snipped portion) of "automated" .

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Dan Pop]

In <3F************ ***@yahoo.com> CBFalconer <cb********@yah oo.com> writes:

Dan Pop wrote:

CBFalconer <cb********@yah oo.com> writes:

... snip ...

> However I have found no /reasonable/ way to regression test my
> nmalloc package, since the pointers it returns depend on the
> state of the rest of the machine.

If you have problems testing a malloc package, it's most likely
due to its extremely bad design.

I think it is high time for you to take Richards refresher course
in Reading for Comprehension, after which you can consider the
"/reasonable/" and "regression test" above, and the implication
(from the snipped portion) of "automated" .

If you have a valid point to make, it's much better to simply make it.
No amount of sarcasm can replace it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[August Derleth]

Damn Skippy <sk****@damn.in valid.org> wrote in message news:<tp******* *************** **********@4ax. com>...

On Mon, 01 Dec 2003 11:25:41 -0600, Ed Morton
<mo************ ****@lucent.com > wrote:

I'm not 100% against gotos, I've just never seen code that uses gotos
that I personally find more readable than the equivalent without gotos.
I recently wrote a short (200 lines or so) program using gotos just to
see if I could learn to appreciate the benefits wrt error-handling, but
once the error-handling became even moderatly complex (i.e. realisitc!)
the initial simplicity afforded by the gotos fell away. I looked at your
code hoping to learn a good way to use goto for readability.

Ed.
To me,

if ( a) { ... }

reads the same as

if (!a) goto skip_this; { ... } skip_this:

especially, and i will be flamed for this, if you consider the opcodes
which will be generated, on the actual real tangible machine(s) on
which it will run. When you think of it this way, it doesn't matter
whether you use goto or not, cos the CPU will (i.e. JUMP type of
instruction).

Most compilers are optimizing anyway, or at least become so with the
addition of options. gcc, for example, probably knows more about
opcode scheduling on Intel chips than I'll ever want or need to (how
to avoid cache misses, pairing rules, etc.), so I can trust it to
generate optimal code even if I give it human-readable C.

I think the impact of optimizing compilers plus the continuous
increases in chip speed negate the whole notion of manually optimizing
C in that way. If you need to speed things up, give the compiler a few
options. If you really need a speedup, choose a different algorithm.
As a last resort, hand-code some assembly.

So you must decide what is readable, and what other people will think
is readable. Bottom line - if people keep asking you why you have all
those 'goto' statements, it's time to cut back.
Of course, some people will flame you for having any goto statements.
Or break statements. Or subroutines with more than one return
statement. Or assignments. Or ... ;)

Remember, C code will be:
1) compiled and executed or
2) interpreted or
3) in a textbook, hopefully with rules and exceptions
That's probably true, but you still can trust the compiler farther
than you seem willing to.


============ inefficient, inelegant, recommended ===========
Inefficient is relative: If a Pentium burns a few thousand clock
cycles on inefficient assembly, what have I actually lost? Less than a
second.

Inelegant is also in the eye of the beholder: I think the code below
is perfectly readable.

for ( .. ) {
if ( a != b ) {
good=false;
complain();
break;
}
}

if (good) {
process();
}

cleanup_regardl ess:
This label isn't referenced by anything yet. I don't know if that's
warnable, but it certainly looks odd.
cleanup();

============ better? saves one test and one stack variable ===========
Maybe on some machines with some compiler options.

And it isn't very structured: What happens when you want to change the
behavior of the code, perhaps add a test for some edge case in some
instances, instead of simply jumping straght to cleanup_regardl ess
every time? With a subroutine, you simply add a value you can pass in.
With a goto, you either duplicate code to check for the edge case
everywhere that needs it right before the goto (a very poor solution),
you use a global you check at the point you jump to (another poor
solution), or you add another label in your code and modify goto
statements (a third poor substitute for good planning).

for ( .. ) {
if ( a != b ) {
complain();
goto cleanup_regardl ess;
}
}

process();

cleanup_regardl ess:
cleanup();

============ ===========

of course, i hope i never see gotos in something like:
I don't think anyone is here to condone that. I think there would be
more people willing to defend the ALTER verb in COBOL than that mess.

if ( (fp = fopen(szFilenam e)) != NULL ) {
if ( fread (&buf, 1, len, fp) == len ) {
if ( !strncmp ( buf, 4, "JFIF") ) {
process_jfif();
}
}
}

[Randy Howard]

In article <br**********@s unnews.cern.ch> , Da*****@cern.ch says...

In <3F************ ***@yahoo.com> CBFalconer <cb********@yah oo.com> writes:

I think it is high time for you to take Richards refresher course
in Reading for Comprehension, after which you can consider the
"/reasonable/" and "regression test" above, and the implication
(from the snipped portion) of "automated" .

If you have a valid point to make, it's much better to simply make it.
No amount of sarcasm can replace it.

Dan

No question, the use of terms and phrases such as "stupid", "idiot",
"engage your brain", "what a stupid poster", "are you so pathetically
stupid", "If you're so stupid that ...", "This is downright idiotic",
"moron", etc. are far better ways to make a point, right Dan?

--
Randy Howard _o
2reply remove FOOBAR \<,
_______________ _______()/ ()_____________ _______________ _______________ ___
SCO Spam-magnet: po********@sco. com

[Dan Pop]

In <MP************ ************@ne ws.megapathdsl. net> Randy Howard <ra**********@F OOmegapathdslBA R.net> writes:

In article <br**********@s unnews.cern.ch> , Da*****@cern.ch says...

In <3F************ ***@yahoo.com> CBFalconer <cb********@yah oo.com> writes:

>I think it is high time for you to take Richards refresher course
>in Reading for Comprehension, after which you can consider the
>"/reasonable/" and "regression test" above, and the implication
>(from the snipped portion) of "automated" .

If you have a valid point to make, it's much better to simply make it.
No amount of sarcasm can replace it.

Dan

No question, the use of terms and phrases such as "stupid", "idiot",
"engage your brain", "what a stupid poster", "are you so pathetically
stupid", "If you're so stupid that ...", "This is downright idiotic",
"moron", etc. are far better ways to make a point, right Dan?

I never use them *instead* of making a point, but in addition to it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de