[comp.lang.c] Put your code where your mouth is

levy@ttrdc.UUCP (Daniel R. Levy) (04/17/88)

In article <1988Apr15.170753.867@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
# > The best collection of thoughts I have seen on this issue is by Donald
# > Knuth, entitled "Structured Programming with goto Statements"...
# 
# The amusing thing about Knuth's article is that when you subtract out the
# search loops (which can be handled with break or return), the syntax
# example (which can be done *much* more elegantly using ungetc()), and the
# things that any modern compiler (NB the 4BSD VAX compiler is an antique)
# would look after for you... there's nothing left!
# 
# Also left as an exercise for the reader is finding the bug in Knuth's
# hash-table-search code.  (He might possibly have corrected this in the
# reprint; my copy is the original Computing Surveys paper.)  The hazards
# of gotos doth make fools of the best of us...

"Left as an exercise" (being implied in re the ways that Knuth's limited
endorsement of goto can supposedly be refuted) sounds more like "I just don't
want to bother showing why this is true, and anyone who doesn't agree is
a lazy dolt."

Mr. Spencer, put your code where your mouth is.  For each goto example in
Knuth, show us how you would code it to run equally efficiently without
gotos.  Fair enough?
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
|     AT&T Data Systems Group    |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|

henry@utzoo.uucp (Henry Spencer) (04/20/88)

> # Also left as an exercise for the reader is finding the bug in Knuth's
> # hash-table-search code.

For those who don't feel like studying the code, the bug is that the
code infinite-loops if the table is full.  One wonders whether Knuth would
have noticed this if he'd tried to avoid the gotos.

> Mr. Spencer, put your code where your mouth is.  For each goto example in
> Knuth, show us how you would code it to run equally efficiently without
> gotos.  Fair enough?

To put it bluntly, it's not worth my time.  In most cases the obvious goto-
free code is just as efficient as Knuth's, given a modern compiler.  Much
of what Knuth is discussing can be seen as ways of hand-coding the sort
of optimizations that modern compilers do without being asked.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {ihnp4,decvax,uunet!mnetor}!utzoo!henry

levy@ttrdc.UUCP (Daniel R. Levy) (04/22/88)

In article <1988Apr20.072000.384@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
# > # Also left as an exercise for the reader is finding the bug in Knuth's
# > # hash-table-search code.
# 
# For those who don't feel like studying the code, the bug is that the
# code infinite-loops if the table is full.  One wonders whether Knuth would
# have noticed this if he'd tried to avoid the gotos.
# 
# > Mr. Spencer, put your code where your mouth is.  For each goto example in
# > Knuth, show us how you would code it to run equally efficiently without
# > gotos.  Fair enough?
# 
# To put it bluntly, it's not worth my time.  In most cases the obvious goto-
# free code is just as efficient as Knuth's, given a modern compiler.  Much
# of what Knuth is discussing can be seen as ways of hand-coding the sort
# of optimizations that modern compilers do without being asked.

Nice show of arrogance but any reasonable reader must conclude that you have
not proved your case.  You somehow found plenty of time to rail against gotos.
-- 
|------------Dan Levy------------|  Path: ihnp4,<most AT&T machines>!ttrdc!levy
|              AT&T              |  I'm not a real hacker, but I play one on
|       Data Systems Group       |  USENET.  If you think that AT&T endorses
|--------Skokie, Illinois--------|  my opinions, I've a nice bridge to sell ya.

henry@utzoo.uucp (Henry Spencer) (04/24/88)

> # To put it bluntly, it's not worth my time.  In most cases the obvious goto-
> # free code is just as efficient as Knuth's, given a modern compiler...
> 
> Nice show of arrogance but any reasonable reader must conclude that you have
> not proved your case.  You somehow found plenty of time to rail against gotos.

Less than you think; certainly less than it would take to type in several
dozen examples of mostly pretty obvious code.  (How much thought does it take
to recode a four-line example?)  I've already spent about as much time as I
think reasonable on the subject; the reasonable readers will have to look at
Knuth's article and judge for themselves whether I'm right, rather than
expecting me to prove it in nit-picky detail.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {ihnp4,decvax,uunet!mnetor}!utzoo!henry

daveb@geac.UUCP (David Collier-Brown) (04/25/88)

>In article <1988Apr20.072000.384@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
># To put it bluntly, it's not worth my time.  In most cases the obvious goto-
># free code is just as efficient as Knuth's, given a modern compiler.  Much
># of what Knuth is discussing can be seen as ways of hand-coding the sort
># of optimizations that modern compilers do without being asked.

In article <2595@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>Nice show of arrogance but any reasonable reader must conclude that you have
>not proved your case.  You somehow found plenty of time to rail against gotos.

    Well, I can't always claim to be reasonable, but I'll claim
Henry is right.  When I read the Knuth paper, I wondered if the real
subject was optimizing compilers... I sorta recollect I saw at least
one thing that PL/1 would do automagically.
    I will also claim to be a reader...

--dave c-b
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.