Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!decwrl!shelby!bloom-beacon!world!burley
From: burley@world.std.com (James C Burley)
Newsgroups: comp.std.c++
Subject: Re: Proposed Enhancement to select/case (yes, I know...)
Message-ID: <BURLEY.90Sep4054715@world.std.com>
Date: 4 Sep 90 12:47:15 GMT
References: <BURLEY.90Aug30030645@world.std.com> <1420@lupine.NCD.COM>
Sender: burley@world.std.com (James C Burley)
Followup-To: comp.std.c++
Distribution: comp
Organization: The World
Lines: 90
In-Reply-To: rfg@NCD.COM's message of 1 Sep 90 17:12:07 GMT

In article <1420@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:

   In article <BURLEY.90Aug30030645@world.std.com> burley@world.std.com (James C Burley) writes:
   <
   <...But how about this: allow ranges (and, perhaps, lists) on case statements.

   There are two separate questions here.  One concerns case ranges, and the
   other concerns lists.  I perfer to talk about each separately.
   ...
   By the way, I believe that both MetaWare C and g++ implement case ranges via
   a syntax like:

	   case LOW..HIGH:

Yes, my "[low:high]:" syntax is lousy anyway, I like the ".." syntax better.
Do Metaware C and/or g++ allow "..LOW" by itself or "HIGH.." by itself?

   Regarding "case lists", it seems clear that a simple syntax, i.e.:

	   case FOO,BAR:

   won't work because the separator comma could be parsed as the normal comma
   operator, which would mess up everything.  James proposes:

	   case [FOO,BAR]:

   which is more verbose than the simple syntax but which still saves a bit of
   typing relative to:

	   case FOO:
	   case BAR:

My reading of the ANSI C standard tells me "case FOO,BAR:" is invalid because
the case expression must be an integer constant expression and an integer
constant expression may not (in essence) contain any operators at "assignment"-
level precedence and below (including the comma operator).  I even tried this
under THINK C 4.0, and it rejected the comma in that context.

I'm not, however, chomping at the bit to create yet another case where comma
might have a different meaning than otherwise (like "foo(1,2,3);", where the
commas must be interpreted as argument separators), even though that would
be the case only if later we wanted to extend the switch statement to handle
general-expression cases (unlikely, but who knows, maybe PL/I programmers
will take over the ANSI C committee :-).

Since it's purely a convenience feature, as compared to ranges, I'd say let's
forget about lists.  They're nice and neat to the "unaided eye", but why invite
hassle with future generations of C any more than we have to?

   <Anyway, the basic idea of case ranges (and lists of cases) comes from Fortran
   <90, as many of you already know.

   I think not.  I'm pretty sure that case ranges appeared in Pascal long
   before anybody in FORTRAN land ever though of the idea.

My statement was very poorly worded, and further reflects my complete ignorance
of Pascal.  What I meant to say was "the basic idea ... COMES TO ME from
Fortran 90...".  Wanted to give credit where credit was due: plus, the
obnoxious [1:2]: syntax I picked as a sample comes directly from '90, save for
using brackets instead of parens and adding the trailing colon.

Also, I don't know whether Pascal has the "..LOWER", "UPPER.." range forms that
match x<=LOWER and UPPER<=x, respectively.  Those are what really "excite" me;
they're the only part of the whole set of features we've been discussing that
one cannot reliably code around even knowing the actual constant values,
without adding extra "ifs" that some compilers might not know enough to
fold in with their own range-checks on the switch/case domain.  Or whatever.

   <Does anyone know any good reasons NOT to implement some or all of these
   <features in today's C++ and C compilers, with an eye towards codifying them
   <in the next ANSI standards for these languages?

   Apparently, Michael Tiemann could not think of any serious problem with
   case ranges, so he went forth and implemented them.

What does FORTH have to do with this?  (-:

   <I wouldn't suggest putting
   <them into the standards until people had had a couple of years to try them
   <out in real code...

   Right.  Given that this feature has already been in g++ for some time,
   you may consider it "prior art".

So considered!  Thanks!

   // Ron Guilmette  -  C++ Entomologist
   // Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
   // Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.
James Craig Burley, Software Craftsperson    burley@world.std.com