levy@ttrdc.UUCP (Daniel R. Levy) (04/25/88)
In article <1988Apr24.004842.3251@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: # > When faced with multiple occurances of a common section # > of code, one has four choices (any others?): # > 1) some sort of subroutine, # > 2) replicating the code in multiple places, # > 3) some type of big, ugly conditional statement to # > bring unite the occurances, # > 4) goto. # # Remember that there are two separate issues here: what you write, and the # code the compiler generates for it. With modern compilers, the two are # often quite different. This may be highly undesireable in a language used for programming operating systems, where the programmer needs something approaching WYSIWYG capability. C is eminently such a language. I'd rather program a "goto" using an older technology compiler then put in a function call, if your proposed whoop-de-do hyper-global-optimizing compiler is liable to turn my REAL function calls into inline code, unbidden. (OOPS, so THAT'S why I got a 4-megabyte kernel!!!) This isn't just hay. I see on this net reports that PC C-compilers hyper- optimize this way. Their benchmarks beat the band, but the executables they make are elephantine. -- |------------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.
noise@eneevax.UUCP (Johnson Noise) (04/26/88)
Ok, ok. An important thing and a not so important thing. the not so important thing first: I don't use gotos much. I use them once in a while for test puposes etc. For the most part I don't care what you guys think is good, bad, or ugly, *but* (now the important part) LEAVE GOTOS IN THE LANGUAGE!!!! It is not *actively* hurting anyone. It has its uses like the above mentioned. Yeah, I agree there are problems with maintainence etc., but, please, LEAVE GOTOS IN THE LANGUAGE!!!!
boyne@hplvly.HP.COM (Art Boyne) (04/26/88)
In article <1988Apr24.004842.3251@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
# > When faced with multiple occurances of a common section
# > of code, one has four choices (any others?):
# > 1) some sort of subroutine,
# > 2) replicating the code in multiple places,
# > 3) some type of big, ugly conditional statement to
# > bring together the occurances,
# > 4) goto.
#
# Remember that there are two separate issues here: what you write, and the
# code the compiler generates for it. With modern compilers, the two are
# often quite different.
Some of us don't have the ?luxury? of having *modern* compilers to do all
the optimization/whoop-dee-doo for us. We are faced with having to use
rather "primitive" compilers that barely can handle constant folding and
register reuse, and generate 2-3x more code that any 1st semester assembly
language student would. In other words, WYSIWYG. So the two "separate"
issues are not so separate for us real-world types.
Even if the issues were separate, I tend to disagree that goto, used
appropriately, is less readable, understandable, or supportable than
the other alternatives listed above. I have to flip pages of a listing
(or rewindow in an editor) to find the subroutine; replicating the code
makes the routines longer than is considered "nice"; and complex conditional
statements can be unintelligible. And I still have the real-world issues
of code size and execution time to consider.
I stand by my original comments.
Art Boyne, ...!hplabs!hplvly!boynehenry@utzoo.uucp (Henry Spencer) (04/27/88)
> This may be highly undesireable in a language used for programming operating > systems, where the programmer needs something approaching WYSIWYG capability. > C is eminently such a language. In operating systems, the programmer needs something approaching WYSIWYG capability in about 0.01% of the code (although there he needs it badly). Heavy optimization of the rest suits me fine. The people at Mips, among others, have demonstrated that with a few bits of control over the compiler (e.g. volatile), heavily-optimizing compilers work beautifully for operating systems. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
ok@quintus.UUCP (Richard A. O'Keefe) (04/30/88)
In a fine series of postings, kenny@uiucdcsb.cs.uiuc.edu showed us how
the gotos in Knuth's "Structured ... Gotos" could be avoided in a "modern"
language by using
(1) gotos (alias 'break', 'continue', 'return')
(2) adding state variables (the very special case of ungetc())
(3) duplicating code
Dijkstra's original argument against 'goto's was that when you look at a
labelled statement you may have no idea what it means for the program to
have reached that point. While 'break' and 'continue' are tamer than
general gotos, in that they can only be used to exit control structures,
not to enter them improperly, I suggest that they can be much _worse_
for program maintenance than the gotos Knuth was advocating.
What gives me such a crazy idea? The fact that they are anonymous.
If I want to see where a break or continue takes me, I may have to scrabble
around matching braces. The big advantage of a goto in C is that the label
has a name. _If_ you adopt the practice of always flushing labels left,
_if_ you use gotos with _care_, and _if_ you put a comment after each label
saying what it means to be at that point, it can be a lot easier for
someone to figure out what is going on. I will take a goto over "break 2"
any day (fortunately C hasn't got "break 2", but it has been suggested
several times in this newsgroup).
The ideal, of course, is something which combines the clarity of a label
with the tameness of a 'break', to wit a named exit. (Escape functions
are even nicer, but they're not C's style.) While C hasn't got a named
exit, we can get the same effect with macros:
#define BEGIN(id) {
#define END(id) ; id:; }
#define LEAVE(id) goto id
/*example*/
BEGIN(search)
for (i = n; --i >= 0; )
if (a[i] == sought) {
/* "found" processing */
LEAVE(search);
}
/* "not found" processing */
END(search)
A fairly straightforward awk script can be used to check that BEGIN and
END match up and that LEAVE is properly in scope. [Left as an exercise
for the reader (:-).]bts@sas.UUCP (Brian T. Schellenberger) (05/02/88)
In article <2606@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: |In article <1988Apr24.004842.3251@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: |# Remember that there are two separate issues here: what you write, and the |# code the compiler generates for it. With modern compilers, the two are |# often quite different. | |This may be highly undesireable in a language used for programming operating |systems, where the programmer needs something approaching WYSIWYG capability. |C is eminently such a language. I'd rather program a "goto" using an older |technology compiler then put in a function call, if your proposed whoop-de-do |hyper-global-optimizing compiler is liable to turn my REAL function calls into |inline code, unbidden. (OOPS, so THAT'S why I got a 4-megabyte kernel!!!) |This isn't just hay. I see on this net reports that PC C-compilers hyper- |optimize this way. Their benchmarks beat the band, but the executables they |make are elephantine. I've seen this same point made before, without rebuttal, so I'm going to this time. The fact that certain compilers for the IBM Piece of Crap computer produce really fat code due to overzealous in-line code production (a fact which is not established, but never mind that) is *not* an argument for making C into nothing more than a pretty-printer for assembly language. Optimization can apply to space or time, or both. The fact that certain compilers don't make the tradeoffs you want merely means that they are not the ones you want. An ideal optimizing compiler would allow you to tell it the relative priorities of these goals. There are many people programming in C, not because they are doing systems programming, but because it is the most similtaneously portable and useful language available. In any case, any quality implementation allows you turn off all optimization. And if it doesn't, don't buy it. -- --Brian. (Brian T. Schellenberger) ...!mcnc!rti!sas!bts . . . now at 2400 baud, so maybe I'll stop bothering to flame long includes.