problems/risks due to programming language

Paul H. Bethge bethge at wums.wustl.edu
Sat Feb 24 04:05:01 AEST 1990


In article <10839 at june.cs.washington.edu>, machaffi at fred.cs.washington.edu
(Scott MacHaffie) writes:
> In article <8133 at hubcap.clemson.edu>
> billwolf%hazel.cs.clemson.edu at hubcap.clemson.edu writes:
>>   common practice to use break statements by the dozen in order to get 
>>   it to behave reasonably.  A more sensible design would give the switch 
>>   the semantics of the Ada case statement, thereby saving countless lines 
>>   of code through the elimination of all those "break" statements. 
> 
> But it would also ADD countless lines of code:
> 
> ANSI C:
> switch (x) {
> 	case '0': case '1': ... case '9':
> 		digit(x);
> 		break;
> }
> 
> ADA-C:
> switch (x) {
> 	case '0': digit(x);
> 	case '1': digit(x);
> 	...
> 	case '9': digit(x);
> }

Oh, come *ON*!  The situation  where  several  cases  need  to  do
exactly the same thing could easily be handled by a syntax such as
switch (x) {
	case '0', case '1', ... case '9':
		digit(x);
	. . .
}

The only real utility of the fall-through feature  of  the  switch
statement  is  in  the  situation  where  several cases need to do
*almost* the same thing, but some of the cases need to do a little
more  than  others.   This  is  clearly  going  to be a very small
fraction of the uses of the switch statement.

C is not perfect, and it does not need to be perfect to be useful.
No  one is proposing to *change* the switch statement; we are just
sighing about what-might-have-been.

BTW, does not the C switch statement closely resemble the  Fortran
computed  GOTO?  (Sorry, I couldn't help myself.  Please flame via
e-mail; I get lonely sometimes. Oh, yeah :-) :-) :-)

__________________________________________________________________
Paul H. Bethge                               bethge at wums.wustl.edu
Biochemistry, Box 8231                          bethge at wums.bitnet
Washington University
St. Louis, MO 63110                                   314-362-3354



More information about the Comp.lang.c mailing list