switch { } - case for range

[markpapadakis]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

example;
switch (a)
{
case 1 ... 10:
// code
break;

case 11 ... 50:
// code
break;

case 800:
// code
break;

default:
// code
break;
}

 

[Ben Pfaff]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

It's an extension.

 

[BRG]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

example;
switch (a)
{
case 1 ... 10:
// code
break;

case 11 ... 50:
// code
break;

case 800:
// code
break;

default:
// code
break;
}

This doesn't work with VC++ version 8 and I don't recall it working on
earlier versions either.

Brian Gladman

 

[Robert Gamble]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

[snip example]

C doesn't have ranges. What you describe is an extension, one which is
clearly documented as such in the gcc documentation. What version of
VC++ are you using that allows this?

Robert Gamble

 

[markpapadakis]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

[snip example]

C doesn't have ranges. What you describe is an extension, one which is
clearly documented as such in the gcc documentation. What version of
VC++ are you using that allows this?

Robert Gamble

I was wrong. It does not work with VC++. It has been a long while since
I used it and I thought it was supported there as well.

Thank you for the answer to the question.

 

[Clark S. Cox III]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

It's an extension.

 

[jacob navia]

I was checking out the C-FAQ and read here (
http://c-faq.com/misc/nonconstcase.html ) that:
" case labels are limited to single, constant, integral expression ".

However, I have been using case with ranges for a long while ( gcc,
VC++) so either the FAQ calls for an update or those two compilers
provide this functionality as an extension.

example;
switch (a)
{
case 1 ... 10:
// code
break;

case 11 ... 50:
// code
break;

case 800:
// code
break;

default:
// code
break;
}

What is your experience with this extension?

Is it really useful?

How many times did you use it?

I would be interested in knowing if it makjes sense to
implement it in lcc-win32.

jacob

 

[Mark McIntyre]

What is your experience with this extension?

For what its worth, my experience is that its really useful if you're
a Visual Basic programmer trying to write C in the style of VB.

For myself I consider this A Very Bad Idea (tm), never ever try to use
one language in the idiom of another. Consider the early editions of
Num Rec in C as a classic case-study. I mean, why buy a scooter to
haul logs?


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[markpapadakis]

What is your experience with this extension?

Is it really useful?

How many times did you use it?

I would be interested in knowing if it makjes sense to
implement it in lcc-win32.

jacob

I am using it quite often. Its useful it eliminates the need for
conditional statements ( wherever conditional statements can be used,
of course ) , provides for easier to manage/understand code and perhaps
reaps any performance benefits versus conditional statements.

Mark

 

[CBFalconer]

I am using it quite often. Its useful it eliminates the need for
conditional statements ( wherever conditional statements can be
used, of course ) , provides for easier to manage/understand code
and perhaps reaps any performance benefits versus conditional
statements.

Why in heavens name use it and become non-portable, when the
portable code (following) is clearer:

if ((a >= 1) && (a <= 10)) firstcode();
else if ((a > 10) && (a <= 50)) secondcode();
else if (a == 800) thirdcode();
else defaultcode();

 

[Richard Tobin]

Why in heavens name use it and become non-portable, when the
portable code (following) is clearer:

if ((a >= 1) && (a <= 10)) firstcode();
else if ((a > 10) && (a <= 50)) secondcode();
else if (a == 800) thirdcode();
else defaultcode();

That's fine in that case, but I have often had cases where there are a
few large ranges and lots of single cases (e.g. when considering a
character during the parsing of some expression). Of course you can
split it into some tests followed by a switch, but ranges would be
neater and allow the compiler to choose the most efficient set of
comparisons.

-- Richard

 

[Eric Sosman]

Richard Tobin wrote On 09/07/06 08:01,:

That's fine in that case, but I have often had cases where there are a
few large ranges and lots of single cases (e.g. when considering a
character during the parsing of some expression). Of course you can
split it into some tests followed by a switch, but ranges would be
neater and allow the compiler to choose the most efficient set of
comparisons.

Are you looking for

case 'a' ... 'z':
case 'A' ... 'Z':
process_alphabetic(ch);
break;

? If so, CBF's solution (now using isalpha() in a test)
is superior on several grounds, correctness among them.

 

[Richard Tobin]

Are you looking for

case 'a' ... 'z':
case 'A' ... 'Z':
process_alphabetic(ch);
break;

Something not unlike that, but I generally have Unicode values.

? If so, CBF's solution (now using isalpha() in a test)
is superior on several grounds, correctness among them.

Presumably you are referring to the possibility of a system where the
alphabetic characters are not consecutive, but on such a system
isalpha() would not give the right results for my Unicode characters -
I would have to use numeric ranges.

-- Richard

 

[Mark McIntyre]

That's fine in that case, but I have often had cases where there are a
few large ranges and lots of single cases (e.g. when considering a
character during the parsing of some expression). Of course you can
split it into some tests followed by a switch, but ranges would be
neater and allow the compiler to choose the most efficient set of
comparisons.

I would submit that the algo was probably flawed, if you found
yourself in this situation.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Tobin]

That's fine in that case, but I have often had cases where there are a
few large ranges and lots of single cases (e.g. when considering a
character during the parsing of some expression). Of course you can
split it into some tests followed by a switch, but ranges would be
neater and allow the compiler to choose the most efficient set of
comparisons.

[/QUOTE]

I would submit that the algo was probably flawed, if you found
yourself in this situation.

Why is that?

Here's an example. I want to classify Unicode characters according
to whether they are XML 1.1 name characters, name start characters, or
other. What is wrong with writing something like:

/* See http://www.w3.org/TR/xml11/#NT-NameStartChar */
switch(c)
{
case 0x3a: /* colon */
case 0x41...0x5a: /* A-Z */
case 0x5f: /* underscore */
case 0x61...0x7a: /* a-z */
case 0xC0...0xD6:
case 0xD8...0xF6:
case 0xF8...0x2FF:
case 0x370...0x37D:
case 0x37F...0x1FFF:
case 0x200C...0x200D:
case 0x2070...0x218F:
case 0x2C00...0x2FEF:
case 0x3001...0xD7FF:
case 0xF900...0xFDCF:
case 0xFDF0...0xFFFD:
case 0x10000...0xEFFF:
return NameStart;
case 0x2d: /* hyphen */
case 0x2e: /* full stop */
case 0x30...0x39: /* 0-9 */
case 0xb7:
case 0x300...0x36f:
case 0x203f...0x2040:
return NameChar;
default:
return Other;
}

Obviously there are other ways to do it, but I don't see why this way
(which directly reflects the standard it is implementing) is "flawed".

-- Richard

 

[boa]

* Richard Tobin wrote, On 07.09.2006 23:08:
[snip]

case 0x10000...0xEFFF:

Shouldn't that be 0xEFFFF?

Boa

 

[sven.axelsson]

Why in heavens name use it and become non-portable, when the
portable code (following) is clearer:

if ((a >= 1) && (a <= 10)) firstcode();
else if ((a > 10) && (a <= 50)) secondcode();
else if (a == 800) thirdcode();
else defaultcode();

Too bad C didn't keep the range syntax from BCPL. Then you could have
used the even clearer:

if (1 <= a <= 10) firstcode();
else if (10 < a <= 50) secondcode();
else if (a == 800) thirdcode();
else defaultcode();

 

[CBFalconer]

Too bad C didn't keep the range syntax from BCPL. Then you could
have used the even clearer:

if (1 <= a <= 10) firstcode();
else if (10 < a <= 50) secondcode();
else if (a == 800) thirdcode();
else defaultcode();

I disagree. The grammar needed to parse such constructs is a
horror, and the result is all sorts of silly errors. SPL (Algol
based HP System Programming Language for the HP3000) had that
construct, and it created nothing but trouble.

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Mark McIntyre]

Here's an example. I want to classify Unicode characters according
to whether they are XML 1.1 name characters, name start characters, or
other. What is wrong with writing something like:

for starters, case{} is clearly the wrong method for this sort of
process. It'd be a lot easier and clearer with an if statement.

Obviously there are other ways to do it, but I don't see why this way
(which directly reflects the standard it is implementing) is "flawed".

*ahem*
Directly implementing a standard is very likely NOT to be the most
efficient or sensible way to write code. Standards are written to be
understood by humans.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Tobin]

Directly implementing a standard is very likely NOT to be the most
efficient or sensible way to write code. Standards are written to be
understood by humans.

So are programs, I hope.

-- Richard