break label stuff
Jeff Anton
anton at ucbvax.ARPA
Sun Jan 13 08:35:27 AEST 1985
I don't know what to think about all this discussion about
how redefine the break statement to take labels. While it's
probably good to get away from the goto statement, I can't help
but think that this is not the way to go. C has, for the most part,
reached its current level of popularity from UNIX. It was designed
to replace assembly language for the higher level functions of
operating systems. To do this it needed the ability to be coerced
into doing things not directly expressable in ordinary varables.
C did not always have casts. I wonder how many people knew this.
Casts were a much better notational system than the reliance on
loosly checked structure use. Anyway, I should get to my point.
If we adopt a new break statement, are we going to adopt the
analogous change to the continue statement?
I can't keep track of all the variations of the break syntax.
None of them have the immeadate clarity I'm use to in codeing in C.
Could someone point me at a language that has labeled loops
without gotos? I do prefer structured languages. But I don't
agree with the compleate banishment of the unrestricted branch.
In any language, I consider the goto statement perfectly valid
for use to branch out of a nested construct to following code.
(Stay within the same procedure of course.)
Goto's make excellent statements about how carefully code should
be read. If I see a label, I scan for the goto, figure out why
it's needed, and understand what's going on. Goto's are
statements that must be commented. Any statement that does something
complex should be commented, and I consider any situation where
one needs to leave two of more nesting levels suffiantly complex.
This all comes down to what the programmer thinks when he sees
a break or a label. What do the labeled loop people think of
breaking switches?
procsearch: for (proc = proctab; proc < proctab+MAXPROC; proc++) {
do_stuff;
while (busy)
if (cond)
break procsearch;
}
Is this analogous or allowed?
flagsw: switch (*argv[1]) {
case 's':
switch (*argv[2]) {
case 'b':
break flagsw;
...
}
...
}
/* execution comes here after the break */
I strongly object to this type of labeled switch.
I don't think that the language change should be made unless it is
uniform, and I don't think that a compromise can be made between
loop labeling and switch labeling. Carefull use of gotos is
clearer and more consistant I think.
--
_________________________
C knows no bounds.
Jeff Anton
U.C.Berkeley
ucbvax!anton
anton at berkeley.ARPA
More information about the Comp.lang.c
mailing list