gotos

Henry Spencer henry at utzoo.uucp
Sun May 1 09:02:43 AEST 1988


> > Language designers and standardizers do have to consider badly-written
> > existing code...
> 
> Standardizers, yes; designers, no.  If you degisign a language, then there is
> not existing code.

Only if you are designing a totally new language, as opposed to one like C++
that is upward-compatible with an existing language to some degree.  In real
situations as opposed to classroom exercises, upward-compatible extensions
are rather more common than from-scratch designs.

> ANSI isn't considering "badly written" code, aparrently...

Not true, actually.  X3J11 does not feel *compelled* to consider badly-
written existing code.  Sometimes it does, though; there are concessions
to such pragmatic issues here and there, where it doesn't do too much
violence to other objectives.

> although defining "badly written" in a standard that makes something badly
> written is begging the question.

Only if you believe that no previous standard existed, which is wrong.  There
was no *formal* prior standard, and this caused a lot of fuzziness, but there
was consensus on most things.  (Otherwise formal consensus standardization
like X3J11 would be impossible, after all.)  In the absence of a carefully-
written formal standard, there is more room for debate about whether specific
code is badly written, but the term remains meaningful.

> > ... Turning clean human-readable notation into
> > ugly fast code is the compiler's *JOB*.
> 
> You don't agree that less of the same instructions == faster code?

IF other things are equal (they usually aren't), and IF the generated code
is in fact different (it often isn't), then it is faster code.  So what?
Remember, I do not advocate bashing code after the fact to remove gotos;
my experience is that well-organized code never needs them in the first
place, so efficiency comparisons between goto code and bashed versions of
it are irrelevant.

> ...  Are you trying to tell us that you have *NEVER* used a goto?

Disregarding maintenance of goto-containing existing code, which sometimes
is done under time-and-effort constraints that make major cleanup impossible,
I haven't used one in quite a few years.  I wouldn't say "never", but I
don't recall the last occasion.

> How does a goto differ from a break statement when used to exit a for
> statement to the statement immediately after it... pages of code later? ...

If you write such things, I suppose the answer is "not much".  Personally,
I consider *any* form of exit (except a function return) that goes to a
point pages later to be a serious botch.

> Why can't goto's be used, in your book, to handle non-standard conditions?

Because there are better ways.

> > I'm not sure I've ever used a flag just to avoid a goto; certainly I haven't
> > done it recently.	...
> > I've only programmed in C for 13 years.
> 
> What do you write?

Everything from small patches for existing code to quite large programs.
The one major gap in my experience is not much involvement in huge multi-
programmer multi-year projects... which in my opinion are doomed anyway
unless they can be split into manageable pieces.

> For someone as vehnemently against 'noalias' as your .sig implies, how can
> you berate a current language feature? ...

Criticism of new mistakes does not require embracing old ones.  Do remember,
also, that I berate human use of the feature, not its existence -- I have no
quarrel with its use in mechanically-generated code, for example.

> And how can you respect DMR's concept
> of C enough to quote him on it, but not respect his decision to include the
> 'goto' statement?  Your appeal to his authority is a little inconsistent.

Even if one ignores some of the considerations mentioned above, it is quite
possible to respect Dennis's overall concept of the language and his views
on certain specific issues while disagreeing with him on others.
-- 
NASA is to spaceflight as            |  Henry Spencer @ U of Toronto Zoology
the Post Office is to mail.          | {ihnp4,decvax,uunet!mnetor}!utzoo!henry



More information about the Comp.lang.c mailing list