case labels

[aarklon]

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

[Ian Collins]

aa*****@gmail.com wrote:

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

Because they must be compile time constants.

--
Ian Collins.

[sumsin]

On Mar 28, 10:03 am, Ian Collins <[e-mail]:

[e-mail] wrote:

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

Because they must be compile time constants.

--
Ian Collins.

Could you elaborate this concept?

[Ian Collins]

sumsin wrote:

On Mar 28, 10:03 am, Ian Collins <[e-mail]:

>[e-mail] wrote:

>>Hi,
why general integer expressions are not allowed in case labels in
switch statements..????

Because they must be compile time constants.

*Please* don't quote signatures.

>
Could you elaborate this concept?

The language requires case labels to be compile time constants. There
really isn't a concept to elaborate on.

--
Ian Collins.

[Keith Thompson]

Ian Collins <ia******@hotmail.comwrites:

sumsin wrote:

>On Mar 28, 10:03 am, Ian Collins <[e-mail]:

>>[e-mail] wrote:
Hi,
why general integer expressions are not allowed in case labels in
switch statements..????
Because they must be compile time constants.

*Please* don't quote signatures.

>>
Could you elaborate this concept?

The language requires case labels to be compile time constants. There
really isn't a concept to elaborate on.

Unless you want to know *why* the standard imposes this requirement.

The code generated for a switch statement is typically a static jump
table (though it doesn't have to be). The advantage of this is that
the code doesn't have to traverse through various possible values of
the controlling expression to determine where to jump; it's typically
faster than an equivalent if/else chain. The disadvantage is that the
values for all the labels have to be known at compile time so the
compiler can construct the jump table.

Having said that, there's nothing forbidding a compiler from treating
a switch statement like an if/else chain anyway (and it will probably
have to do something like that if the range of cases is very large).

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bartc]

<aa*****@gmail.comwrote in message
news:a3**********************************@m44g2000 hsc.googlegroups.com...

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

There's no reason why switch expressions can't be any (identical) type, as
Keith has suggested.

If they are all constant integers, then fine generate a jump table.
Otherwise generate appropriate if-statements. This is very easy at a time
when C compilers are so super-sophisticated they can almost bake bread too.

But the people responsible for new C standards have decided to keep this
area of the language (control statements in general) at a primitive level.

So the programmer has to code his logic in a less expressive manner.

--
Bart

[Bartc]

"Eric Sosman" <es*****@ieee-dot-org.invalidwrote in message
news:r6******************************@comcast.com. ..

Bartc wrote:

>>
There's no reason why switch expressions can't be any (identical) type,
as Keith has suggested.

If they are all constant integers, then fine generate a jump table.
Otherwise generate appropriate if-statements. This is very easy at a time
when C compilers are so super-sophisticated they can almost bake bread
too.

But the people responsible for new C standards have decided to keep this
area of the language (control statements in general) at a primitive
level.

So the programmer has to code his logic in a less expressive manner.

If you switch on a double, with double case labels,
what's the matching criterion?

....

If you switch on a struct-valued expression, what's
the matching criterion?

....

If you switch on a `char*', should the matching
criterion be strcmp()?

Yes I know there's all sorts of obscure examples where such a switch would
be ambiguous, but in that case no advance would ever be made.

Probably all the OP wants is to be have variable int cases, then an
extension of switch which simply applies the == operator would be a useful
advance.

Another simple enhancement is a range operator (maybe gcc has this?) like
case 'A'..'Z':, which in the case of doubles could translate into >= and <=.
And with char* strings, the compiler can apply some common sense and use
strcmp(). There are ways.

If you've got ideas of how to handle questions of this
kind, get hold of the gcc source and implement your answers.
Then float it around to see whether people like it; if
they do, you'll have taken a big step towards getting it
into a revised Standard -- "prior art" is a lot more
convincing than "I wish."

I've worked on a compiler for a language where something similar is possible
(although I found it easier to have two forms of switch: one with constant
int cases, and one with any simple type where =/== made sense). And it was
workable.

But no I don't fancy delving into the gcc sources!

--
Bart

[Chris Dollin]

Eric Sosman wrote:

(fx:dreaming)

If you switch on a struct-valued expression, what's
the matching criterion?

struct_Foo_switch_equality
( struct Foo *switched, struct Foo *cased );

struct_Foo_hash_value
( struct Foo *foo );

If you switch on a `char*', should the matching
criterion be strcmp()? Or caseInsensitiveStrcmp()? Or
allWhiteSpaceCountsAsIdenticalStrcmp()?

strcmp. If the user wants something else, they can canonise
their switched string first. (And I'm imagining a `strhash`.)

I grant that an implementation is more convincing than a handwave is.

Getting non-unfortunate performance might be more of a problem than
mere semantics. (Hence the hashes.)

--
"Its flagships were suns, its smallest vessels, /The City and the Stars/
planets."

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Eric Sosman]

Bartc wrote:

"Eric Sosman" <es*****@ieee-dot-org.invalidwrote in message
news:r6******************************@comcast.com. ..

>Bartc wrote:

>>There's no reason why switch expressions can't be any (identical) type,
as Keith has suggested.

If they are all constant integers, then fine generate a jump table.
Otherwise generate appropriate if-statements. This is very easy at a time
when C compilers are so super-sophisticated they can almost bake bread
too.

But the people responsible for new C standards have decided to keep this
area of the language (control statements in general) at a primitive
level.

So the programmer has to code his logic in a less expressive manner.

If you switch on a double, with double case labels,
what's the matching criterion?

...

> If you switch on a struct-valued expression, what's
the matching criterion?

...

> If you switch on a `char*', should the matching
criterion be strcmp()?

Yes I know there's all sorts of obscure examples where such a switch would
be ambiguous, but in that case no advance would ever be made.

The question is whether the "advance" produces something
useful, and the situations I mentioned seem to me like real-
life problems the enhanced switch would have trouble with.

Probably all the OP wants is to be have variable int cases, then an
extension of switch which simply applies the == operator would be a useful
advance.

The O.P. in this case asked a very short question, from
which you seem to derive a lot more information than I can.

Besides, I'm still not convinced of the utility, even
if restricted to int values. Try this:

int x = 42, y = 43;
for (int i = 40; i < 50; ++i) {
switch (i) {
case x: printf("x\n"); break;
case y: printf("y\n"); break;
default: printf("?\n"); break;
}
y = 42;
}

Worse still, try this:

int c1, c2;
c1 = getchar();
switch (c1) {
case EOF: printf("done!\n"); return;
case c2 = getchar():
printf("two %c's in a row\n", c1);
break;
default:
ungetc(c2); break;
}

Question: Is the "internal" getchar() executed if c1==EOF?

Another simple enhancement is a range operator (maybe gcc has this?) like
case 'A'..'Z':, which in the case of doubles could translate into >= and <=.

Yes, gcc has an extension like this. And yes, it's less
useful than one might think. For example, the case you show
does necessarily select all upper-case letters, nor does it
necessarily exclude all non-letters. What good is it?

Case ranges might be handy in some other situations, but
it seems suggestive that the example always offered for them
is the one you've shown, where ranges are clearly *not* the
right thing to use.

And with char* strings, the compiler can apply some common sense and use
strcmp(). There are ways.

... so the enhanced switch is limited to just one notion
of matching. True, it's probably the most "natural" notion
for strings, but it's not the only notion. Also, what do
you get if the char* you switch on (or one of the labels)
is NULL? What if it's just a char* that points at a char,
but not at the start of a string?

I've worked on a compiler for a language where something similar is possible
(although I found it easier to have two forms of switch: one with constant
int cases, and one with any simple type where =/== made sense). And it was
workable.

I'm not saying that definitions could not be invented to
nail down these loose bits; other languages have certainly
come up with switch-ish constructs that handle at least some
of the difficulties. But is it worth the trouble? I'm not
sure -- and that's why I suggested doing an implementation
and finding out whether people would use the feature in
interesting ways.

But no I don't fancy delving into the gcc sources!

Well, if the advance isn't worth some fairly serious
work, that may mean the need it addresses isn't too urgent.

--
Er*********@sun.com

[CBFalconer]

aa*****@gmail.com wrote:

>
why general integer expressions are not allowed in case labels in
switch statements..????

Because a common switch implementation is an indexed jump through a
fixed table of destinations.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[aarklon]

On Mar 28, 2:18 am, Ian Collins <[e-mail]:

sumsin wrote:

On Mar 28, 10:03 am, Ian Collins <[e-mail]:

[e-mail] wrote:
Hi,
why general integer expressions are not allowed in case labels in
switch statements..????
Because they must be compile time constants.

*Please* don't quote signatures.

Could you elaborate this concept?

The language requires case labels to be compile time constants. There
really isn't a concept to elaborate on.

The real elaborate question i wanted to ask was

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

[Richard Tobin]

In article <ea**********************************@d4g2000prg.g ooglegroups.com>,
<aa*****@gmail.comwrote:

>The real elaborate question i wanted to ask was

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

Why not run a C course and ask your students?

-- Richard
--
:wq

[lawrence.jones]

Keith Thompson <ks***@mib.orgwrote:

>
Having said that, there's nothing forbidding a compiler from treating
a switch statement like an if/else chain anyway (and it will probably
have to do something like that if the range of cases is very large).

Indeed, most compilers have a number of different strategies for
implementing switch statements that they choose from based on things
like the number of cases, their range, and density.

-Larry Jones

When I want an editorial, I'll ASK for it! -- Calvin

[jacob navia]

la************@siemens.com wrote:

Keith Thompson <ks***@mib.orgwrote:

>Having said that, there's nothing forbidding a compiler from treating
a switch statement like an if/else chain anyway (and it will probably
have to do something like that if the range of cases is very large).

Indeed, most compilers have a number of different strategies for
implementing switch statements that they choose from based on things
like the number of cases, their range, and density.

Yes. Lcc-win will produce a if/else if the number of case
is less equal to 3.

-Larry Jones

When I want an editorial, I'll ASK for it! -- Calvin

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[lawrence.jones]

aa*****@gmail.com wrote:

>
why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

Restricting case labels to integer constant expressions allows various
highly efficient implementations. For general expressions, there's no
more efficient implementation than a sequence of if ... else if ...
statements. Since you can already write the sequence of statements if
you need it, allowing you to write it as a switch as well wouldn't add
much expressive power but it would complicate the description of the
language and the implementation of the compiler somewhat. DMR decided
that the benefit wasn't worth the cost.

-Larry Jones

Nothing spoils fun like finding out it builds character. -- Calvin

[jacob navia]

la************@siemens.com wrote:

aa*****@gmail.com wrote:

>why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

Restricting case labels to integer constant expressions allows various
highly efficient implementations. For general expressions, there's no
more efficient implementation than a sequence of if ... else if ...
statements. Since you can already write the sequence of statements if
you need it, allowing you to write it as a switch as well wouldn't add
much expressive power but it would complicate the description of the
language and the implementation of the compiler somewhat. DMR decided
that the benefit wasn't worth the cost.

-Larry Jones

Nothing spoils fun like finding out it builds character. -- Calvin

This is correct. But I think allowing case *ranges* would not affect
the generality of the optimization. lcc-win, for instance, generates
several secondary tables in the optimized search tree, when there are
different disjoint ranges of case values.

case 1: case 2: case 3:
//
break;

case 1459: case 1460: case 1461:
//
break;
We could write the same switch with less effort if we had:

case 1...3:
//
break;
case 1459...1461:
//
break;

The ellipsis token exists already. Nothing would be more easy to do.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ben Pfaff]

jacob navia <ja***@nospam.comwrites:

We could write the same switch with less effort if we had:

case 1...3:
//
break;
case 1459...1461:
//
break;

No, not exactly like that:

The ellipsis token exists already. Nothing would be more easy to do.

The ellipsis token exists, but neither case statement above
contains an ellipsis token. Instead, each of them contains a
floating point number followed by characters that do not form
valid tokens.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Ian Collins]

jacob navia wrote:

la************@siemens.com wrote:

>>
Nothing spoils fun like finding out it builds character. -- Calvin

This is correct.

Speaking form experience?

--
Ian Collins.

[christian.bau]

On Mar 28, 5:48*pm, [e-mail] wrote:

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general integer
expressions instead of constant integer expressions? discuss both user
convenience and implementation aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general mental
health aspects.

[Bartc]

christian.bau wrote:

On Mar 28, 5:48 pm, [e-mail] wrote:

>why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general
integer expressions instead of constant integer expressions? discuss
both user convenience and implementation aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general mental
health aspects.

No different to:

if (i==f())
printf("f");
else if (i==g())
printf("g");

which is perfectly legal. It's a question of freedom of expression.

--
Bart

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.eduwrites:

jacob navia <ja***@nospam.comwrites:

>We could write the same switch with less effort if we had:

case 1...3:
//
break;
case 1459...1461:
//
break;

No, not exactly like that:

>The ellipsis token exists already. Nothing would be more easy to do.

The ellipsis token exists, but neither case statement above
contains an ellipsis token. Instead, each of them contains a
floating point number followed by characters that do not form
valid tokens.

Actually, ``1...3'' and ``1459...1461'' are both valid preprocessor
numbers (pp-numbers) (C99 6.4.8). These preprocessor tokens are
supposed to be converted into tokens in translation phase 7 (C99
5.1.1.2), but the conversion obviously can't succeed. I haven't been
able to find an explicit statement about what's supposed to happen if
a pp-token to token conversion fails; it's at least undefined
behavior.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

"christian.bau" wrote:

[e-mail] wrote:

>why are constant integer expressions required in case labels of
the switch statement? what would be the impact of allowing
general integer expressions instead of constant integer
expressions? discuss both user convenience and implementation
aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general
mental health aspects.

The function f() is not a constant integer expression. Illegal.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

"christian.bau" wrote:

>[e-mail] wrote:

>>why are constant integer expressions required in case labels of
the switch statement? what would be the impact of allowing
general integer expressions instead of constant integer
expressions? discuss both user convenience and implementation
aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general
mental health aspects.

The function f() is not a constant integer expression. Illegal.

Yes, of course it's illegal. That's the point. The example was
intended to illustrate *why* it's illegal (beyond "because the
standard says so").

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bartc]

"Keith Thompson" <ks***@mib.orgwrote in message
news:87************@kvetch.smov.org...

CBFalconer <cb********@yahoo.comwrites:

>"christian.bau" wrote:

>>[e-mail] wrote:

why are constant integer expressions required in case labels of
the switch statement? what would be the impact of allowing
general integer expressions instead of constant integer
expressions? discuss both user convenience and implementation
aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general
mental health aspects.

The function f() is not a constant integer expression. Illegal.

Yes, of course it's illegal. That's the point. The example was
intended to illustrate *why* it's illegal (beyond "because the
standard says so").

Maybe I've missed something but how does this example show that it should be
illegal?

I thought possibly all case values need to be considered simultaneously
(difficult with variable expressions) but my C reference says nothing of
this. It does say no two values can be the same (again not easy with
variables), but this is an enhanced switch and the standard cannot cover it.

--
Bart

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

>
This is correct. But I think allowing case *ranges* would not affect
the generality of the optimization. lcc-win, for instance, generates
several secondary tables in the optimized search tree, when there are
different disjoint ranges of case values.

Yes, case ranges were seriously considered for C99 but ultimately were
rejected because they're less useful than they appear at first glance
and are an open invitation to lead novice programmers astray. For
example, an obvious range is 'A'...'Z', but that doesn't have the
generally expected behavior on many systems (e.g., IBM mainframes use
EBCDIC which has a number of interesting non-alphabetic characters
scattered amongst the letters).

-Larry Jones

I think my cerebellum just fused. -- Calvin

[James Dow Allen]

On Mar 28, 5:58*am, "Bartc" <[e-mail]:

Yes I know there's all sorts of obscure examples where such
a switch would
be ambiguous, but in that case no advance would ever be made.

The "obscure example" IIRC was "f()" -- is this a bizarre
construct? Are there standard C idioms that are ambiguous?

The idea that ambiguous expressions are fine (a "smart"
compiler will guess the most likely or most "friendly"
interpretation) may be in tune with post-modernism,
but it is not the C philosophy.

If you're looking for an overly complex language
with lots of hand-holding, hundreds of complicated
rules to memorize so somebody can save a keystroke,
then c.l.c is the wrong newsgroup.

James Dow Allen

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 28 Mar 2008 18:02:38 -0700, Keith Thompson wrote:

Actually, ``1...3'' and ``1459...1461'' are both valid preprocessor
numbers (pp-numbers) (C99 6.4.8). These preprocessor tokens are
supposed to be converted into tokens in translation phase 7 (C99
5.1.1.2), but the conversion obviously can't succeed. I haven't been
able to find an explicit statement about what's supposed to happen if a
pp-token to token conversion fails; it's at least undefined behavior.

It's a constraint violation. C99 6.4p1 reads "Each preprocessing token
that is converted to a token shall have the lexical form of a keyword, an
identifier, a constant, a string literal, or a punctuator."

[Peter Nilsson]

Harald van D©¦k <[e-mail]:

Keith Thompson wrote:

Actually, ``1...3'' and ``1459...1461'' are both
valid preprocessor numbers (pp-numbers) (C99 6.4.8).
These preprocessor tokens are supposed to be converted
into tokens in translation phase 7 (C99 5.1.1.2), but
the conversion obviously can't succeed. I haven't
been able to find an explicit statement about what's
supposed to happen if a pp-token to token conversion
fails; it's at least undefined behavior.

It's a constraint violation. C99 6.4p1 reads "Each
preprocessing token that is converted to a token shall
have the lexical form of a keyword, an identifier, a
constant, a string literal, or a punctuator."

Nit: 6.4p2.

--
Peter

[Harald van =?UTF-8?b?RMSzaw==?=]

On Fri, 28 Mar 2008 23:49:59 -0700, Peter Nilsson wrote:

Harald van Dijk <[e-mail]:

>It's a constraint violation. C99 6.4p1 reads "Each preprocessing token
that is converted to a token shall have the lexical form of a keyword,
an identifier, a constant, a string literal, or a punctuator."

Nit: 6.4p2.

Oops. You're right, of course.

[Flash Gordon]

la************@siemens.com wrote, On 29/03/08 01:17:

jacob navia <ja***@nospam.comwrote:

>This is correct. But I think allowing case *ranges* would not affect
the generality of the optimization. lcc-win, for instance, generates
several secondary tables in the optimized search tree, when there are
different disjoint ranges of case values.

Yes, case ranges were seriously considered for C99 but ultimately were
rejected because they're less useful than they appear at first glance
and are an open invitation to lead novice programmers astray. For
example, an obvious range is 'A'...'Z', but that doesn't have the
generally expected behavior on many systems (e.g., IBM mainframes use
EBCDIC which has a number of interesting non-alphabetic characters
scattered amongst the letters).

I don't think that is a very good argument against it. The people who
would make that mistake are the people who currently do:
if (c>='A' && c<='Z')
so by forbidding ranges you are not, IMO, reducing errors just
preventing people from using a potentially useful feature.
--
Flash Gordon

[Bartc]

James Dow Allen wrote:

On Mar 28, 5:58 am, "Bartc" <[e-mail]:

>Yes I know there's all sorts of obscure examples where such
a switch would
be ambiguous, but in that case no advance would ever be made.

The "obscure example" IIRC was "f()" -- is this a bizarre
construct? Are there standard C idioms that are ambiguous?

That was from a different post. The ambiguities here are from Eric Sosman's
examples, where perhaps a simple == match may not be the best.

The idea that ambiguous expressions are fine (a "smart"
compiler will guess the most likely or most "friendly"
interpretation) may be in tune with post-modernism,
but it is not the C philosophy.

Read this newsgroup some more. There are plenty of ambiguities!

>
If you're looking for an overly complex language
with lots of hand-holding, hundreds of complicated
rules

Such as, 'a switch-case expression must be an integer constant'?.

to memorize so somebody can save a keystroke,
then c.l.c is the wrong newsgroup.

--
Bart

[CBFalconer]

Flash Gordon wrote:

Eric Sosman wrote:

.... snip ...

>

> If someone's got an example where case ranges would be
significantly more useful and expressive, I'd be glad to see it.

I've used the equivalent in Pascal a few times, but I don't have
an example conveniently to hand. However, off the top of my head
one example could be...

Then you have used an illegal Pascal construct, or a poorly
conceived extension in the system. Ranges are also forbidden in
case statements in Pascal. See ISO7185.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 29 Mar 2008 10:22:20 -0500, CBFalconer wrote:

Flash Gordon wrote:

>Eric Sosman wrote:

... snip ...

>>

>> If someone's got an example where case ranges would be
significantly more useful and expressive, I'd be glad to see it.

I've used the equivalent in Pascal a few times, but I don't have an
example conveniently to hand. However, off the top of my head one
example could be...

Then you have used an illegal Pascal construct, or a poorly conceived
extension in the system. Ranges are also forbidden in case statements
in Pascal. See ISO7185.

Ranges are not forbidden in case statements in Pascal. See ISO10206.
Extended Pascal is also standardised.

[Flash Gordon]

CBFalconer wrote, On 29/03/08 15:22:

Flash Gordon wrote:

>Eric Sosman wrote:

... snip ...

>> If someone's got an example where case ranges would be
significantly more useful and expressive, I'd be glad to see it.

I've used the equivalent in Pascal a few times, but I don't have
an example conveniently to hand. However, off the top of my head
one example could be...

Then you have used an illegal Pascal construct, or a poorly
conceived extension in the system. Ranges are also forbidden in
case statements in Pascal. See ISO7185.

OK, so it was an extension. This was a long time ago. However it was
still a useful extension and I've yet to see any argument against it
that does not also apply to if statements.
--
Flash Gordon

[Richard Tobin]

In article <ss******************************@comcast.com>,
Eric Sosman <es*****@ieee-dot-org.invalidwrote:

>switch (cmdcode)
{case 1000..1999: filecmds(); break
case 2000..2499: editcmds(); break;
case 2500..2999: viewcmds(); break
default: misccmds();
};

Did you find this (or its equivalent) in an actual
program, or did you simply make it up?

It does seem rather contrived, but I can imagine something similar
for the handling of error codes:

switch(status)
{
case 100..199:
handle_informational(); break;
case 200..299:
handle_success(); break;
case 300..399:
handle_redirection(); break;
case 400..499:
handle_client_error(); break;
case 500..599:
handle_server_error(); break;
}

The numbers and categories are taken from the HTTP protocol:

http://www.w3.org/Protocols/rfc2616/....html#sec6.1.1

I have several times wanted a range for some of the cases when
processing characters (known to be Unicode, so the encoding doesn't
come into it).

-- Richard
--
:wq

[Ben Pfaff]

"Bartc" <[e-mail]:

OK, let's try:

switch (cmdcode)
{case 1000..1999: filecmds(); break
case 2000..2499: editcmds(); break;
case 2500..2999: viewcmds(); break
default: misccmds();
};

C99 imposes a limit of 1023 case values in a switch statement, so
that switch statement would require at least one more extension
beyond case ranges.
--
"Programmers have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_

[Bartc]

"Ben Pfaff" <bl*@cs.stanford.eduwrote in message
news:87************@blp.benpfaff.org...

"Bartc" <[e-mail]:

>OK, let's try:

switch (cmdcode)
{case 1000..1999: filecmds(); break
case 2000..2499: editcmds(); break;
case 2500..2999: viewcmds(); break
default: misccmds();
};

C99 imposes a limit of 1023 case values in a switch statement, so
that switch statement would require at least one more extension
beyond case ranges.

That seems overly restrictive. I guess the rule is there to limit the number
of /individual/ case-expressions so that the compiler can cope. But my
example above has only 3.. or maybe 6. So yes the rule would need modifying
a little.

--
Bart

[Ben Pfaff]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

It does seem rather contrived, but I can imagine something similar
for the handling of error codes:

switch(status)
{
case 100..199:
handle_informational(); break;
case 200..299:
handle_success(); break;
case 300..399:
handle_redirection(); break;
case 400..499:
handle_client_error(); break;
case 500..599:
handle_server_error(); break;
}

You could just switch on status / 100.

--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Richard Tobin]

In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:

> switch(status)
{
case 100..199:
handle_informational(); break;

[...]

>You could just switch on status / 100.

I'm not recommending this style, just trying to give a plausible
use of it.

-- Richard
--
:wq

[lawrence.jones]

Richard Tobin <ri*****@cogsci.ed.ac.ukwrote:

>
It does seem rather contrived, but I can imagine something similar
for the handling of error codes:

switch(status)
{
case 100..199:
handle_informational(); break;
case 200..299:
handle_success(); break;
case 300..399:
handle_redirection(); break;
case 400..499:
handle_client_error(); break;
case 500..599:
handle_server_error(); break;
}

switch(status/100)
{
case 1:
handle_informational(); break;
case 2:
handle_success(); break;
case 3:
handle_redirection(); break;
case 4:
handle_client_error(); break;
case 5:
handle_server_error(); break;
}

-Larry Jones

I don't think that question was very hypothetical at all. -- Calvin

[CBFalconer]

Eric Sosman wrote:

Bartc wrote:

.... snip ...

>>
OK, let's try:

switch (cmdcode)
{case 1000..1999: filecmds(); break
case 2000..2499: editcmds(); break;
case 2500..2999: viewcmds(); break
default: misccmds();
};

Did you find this (or its equivalent) in an actual
program, or did you simply make it up? My point is not
that a ranged-case switch cannot be imagined, but that
its actual utility is in doubt. Can you find an example
of a real program -- or even a realistic programming
situation -- where case ranges would be helpful?

A more reasonable, and legal, coding would be:

if ((cmdcode < 1000) || (cmdcode 2999)) misccmds();
else if (cmdcode < 2000) filecmds();
else if (cmdcode < 2500) editcmds();
else viewcmds();

which I consider readable and legitimate.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Harald van D?k wrote:

CBFalconer wrote:

>Flash Gordon wrote:

>>Eric Sosman wrote:

... snip ...

>>>
If someone's got an example where case ranges would be
significantly more useful and expressive, I'd be glad to see it.

I've used the equivalent in Pascal a few times, but I don't have
an example conveniently to hand. However, off the top of my head
one example could be...

Then you have used an illegal Pascal construct, or a poorly
conceived extension in the system. Ranges are also forbidden in
case statements in Pascal. See ISO7185.

Ranges are not forbidden in case statements in Pascal. See ISO10206.
Extended Pascal is also standardised.

That's extended Pascal, not Pascal. That's something like
confusing C++ and C (but not as bad). :-)

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sat, 29 Mar 2008 23:32:37 -0500, CBFalconer wrote:

Harald van D?k wrote:

>Ranges are not forbidden in case statements in Pascal. See ISO10206.
Extended Pascal is also standardised.

That's extended Pascal, not Pascal. That's something like confusing C++
and C (but not as bad). :-)

Considering the support for it by both implementors and users, it's
closer to C99 than C++. :)

[Flash Gordon]

CBFalconer wrote, On 30/03/08 05:40:

Eric Sosman wrote:

>Bartc wrote:

... snip ...

>>OK, let's try:

switch (cmdcode)
{case 1000..1999: filecmds(); break
case 2000..2499: editcmds(); break;
case 2500..2999: viewcmds(); break
default: misccmds();
};

Did you find this (or its equivalent) in an actual
program, or did you simply make it up? My point is not
that a ranged-case switch cannot be imagined, but that
its actual utility is in doubt. Can you find an example
of a real program -- or even a realistic programming
situation -- where case ranges would be helpful?

A more reasonable, and legal, coding would be:

if ((cmdcode < 1000) || (cmdcode 2999)) misccmds();
else if (cmdcode < 2000) filecmds();
else if (cmdcode < 2500) editcmds();
else viewcmds();

which I consider readable and legitimate.

Personally I find the if chain version to be less readable, less
maintainable and more error prone. It's what I do in C because it is the
only mechanism C provides, but that does not make it the best way it
could be done.
--
Flash Gordon

[CBFalconer]

Bartc wrote:

"CBFalconer" <cb********@yahoo.comwrote in message

.... snip ...

>

> if ((cmdcode < 1000) || (cmdcode 2999)) misccmds();
else if (cmdcode < 2000) filecmds();
else if (cmdcode < 2500) editcmds();
else viewcmds();

which I consider readable and legitimate.

The code below is virtually identical to my fragment above and
compiles and runs with gcc.

.... snip ...

>
switch (cmdcode)
{case 1000 ... 1999: filecmds(cmdcode); break;
case 2000 ... 2499: editcmds(cmdcode); break;
case 2500 ... 2999: viewcmds(cmdcode); break;
default: misccmds(cmdcode);
};

It is still not acceptable to standard C. In addition, if you
examine the generated code, you may find that is has been converted
to my code in the first place, or that it is generating a 2000
entry transfer table (may depend on optimization), which is not
exactly optimum code. It doesn't hurt to have a rough idea of what
the compiler generates.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Richard Bos]

Ben Pfaff <bl*@cs.stanford.eduwrote:

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

It does seem rather contrived, but I can imagine something similar
for the handling of error codes:

switch(status)
{
case 100..199:
handle_informational(); break;
case 200..299:
handle_success(); break;
case 300..399:
handle_redirection(); break;
case 400..499:
handle_client_error(); break;
case 500..599:
handle_server_error(); break;
}

You could just switch on status / 100.

switch(status) {
case 100..149:
handle_informational(); break;
case 200..299:
handle_success(); break;
case 300..317:
handle_redirection(); break;
case 400..448:
handle_client_error(); break;
case 500..572:
handle_server_error(); break;
default:
handle_protocol_failure(); break;
}

Also, for clarity, use #defined constants called STAT_INFO_START and
STAT_INFO_END, and similar for the other categories.

Richard

[Chris Dollin]

CBFalconer wrote:

"christian.bau" wrote:

>[e-mail] wrote:

>>why are constant integer expressions required in case labels of
the switch statement? what would be the impact of allowing
general integer expressions instead of constant integer
expressions? discuss both user convenience and implementation
aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general
mental health aspects.

The function f() is not a constant integer expression. Illegal.

Chuck, that's a completely missing-the-point answer; we /know/ that
`f()` isn't a CIE.

You've been doing this sort of thing a /lot/ recently. I don't
know why, so my proposed solutions -- re-read before posting,
cut back on threads, coffee control, loud prog rock during commute --
may not work for you.

--
"Thereafter, events may roll unheeded." /Foundation/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Richard]

"Bartc" <[e-mail]:

christian.bau wrote:

>On Mar 28, 5:48 pm, [e-mail] wrote:

>>why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general
integer expressions instead of constant integer expressions? discuss
both user convenience and implementation aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general mental
health aspects.

No different to:

if (i==f())
printf("f");
else if (i==g())
printf("g");

which is perfectly legal. It's a question of freedom of expression.

You need to think about the lines with or without break statements too
-this would then make the "else" incorrect. Do all the case functions
get execed or not? So no, in the absence of "case f()" being defined
nothing is obvious at all.

[Bartc]

Richard wrote:

"Bartc" <[e-mail]:

>christian.bau wrote:

>>On Mar 28, 5:48 pm, [e-mail] wrote:

why are constant integer expressions required in case labels of the
switch statement? what would be the impact of allowing general
integer expressions instead of constant integer expressions?
discuss both user convenience and implementation aspects?

Consider

switch (i) {
case f (): printf ("f"); break;
case g (): printf ("g"); break;
}

Discuss under user convenience, implementation, and general mental
health aspects.

No different to:

if (i==f())
printf("f");
else if (i==g())
printf("g");

which is perfectly legal. It's a question of freedom of expression.

You need to think about the lines with or without break statements too
-this would then make the "else" incorrect. Do all the case functions
get execed or not? So no, in the absence of "case f()" being defined
nothing is obvious at all.

You're right, 'break' is a bit of a nuisance, apart from spoiling the lines
of the somewhat cleaner code using switch.

But nevertheless it could be handled I think: with no breaks in the switch
example above, the if-version just becomes:

if (i==f()) {
printf("f");
goto L003;
}
if (i==g()) {
L003:
printf("g");
};

When case f() is false then the next case is tested, until a true case if
found. Then with break it will exit the whole block of cases, without break
it continues to the next case-body.

--
Bart

[John J. Smith]

aa*****@gmail.com wrote:

Hi,

why general integer expressions are not allowed in case labels in
switch statements..????

If these expressions are not compile time constants, there's no guarantee
all case labels are unique. Consider..

extern int foo, bar;
int n;

/*...*/
n = 42;
switch(n)
{
case foo:
do_foo();
break;

case bar:
do_bar();
break;

default:
do_default();
break;
}

If foo and bar happen to have the same value (42), which branch should
be taken? The first matching one? All of them?

(Note that C disallows duplicate case labels probably for that reason)

--
John J. Smith