mod.std.c Digest Volume 3 : Issue 10
Orlando Sotomayor-Diaz
osd7 at homxa.UUCP
Mon Feb 25 14:07:49 AEST 1985
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sun, 24 Feb 85 Volume 3 : Issue 10
Today's Topics:
Case >20
----------------------------------------------------------------------
Date: Sun, 24 Feb 85 05:00:53 est
From: cbosgd!hcr!lsuc!msb
Subject: Case >20
To: hcr!cbosgd!std-c
Kevin Martin suggests adding forms such as "case >20:" to C,
as have been used in B for some years. Craig Partridge prefers
to use defaults for these. I think Kevin is right, and here's an
example of why.
enum class
charclass (c)
char c;
{
switch ((unsigned) c) {
case 0011 .. 0015:
case 0040:
return SPACE;
case > 0177:
return HIGHBIT;
case 0041 .. 0176:
return GRAPHIC;
case < 0010:
case 0016 .. 0037:
case 0177:
return CONTROL;
}
}
Sure, there are lots of better ways to write this simple example.
But the point is now that I can, as I've always wanted, write
things like "case 0016 .. 0037: case 0177:", it seems sensible
to allow me to combine "case < 0010:" with it. But if the
cases < 0010 and > 0177 are combined as default, this requires a
goto or a drop-through. I submit that inequality ranges are better.
There is one side point. Notice that in the above example if I
added a default it would NEVER be executed. I think this should
be grounds for a compiler warning.
It might be said against the proposed extension that it permits eccentric
use of default, to designate a small range or even a single case value,
and this would be style we don't want to encourage. All I will say
to this is that anything can be abused.
{ allegra | decvax | duke | ihnp4 | linus | watmath | ... } !utzoo!lsuc!msb
also via { hplabs | amd | ... } !pesnta!lsuc!msb
Mark Brader and uw-beaver!utcsri!lsuc!msb
(utcsri used to be utcsrgv)
------------------------------
End of mod.std.c Digest - Sun, 24 Feb 85 23:05:49 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.
More information about the Mod.std.c
mailing list