C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression"

[Kenny McCormack]

Re: C/C++ language proposal: Change the 'case expression' from "integralc onstant-expression&quot ; to "integr al expression&quot ;

In article <lnbpx9z85p.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:
....

>Which completely and utterly misses the point.

It's what Chuck does best. One should always play to one's strengths.

[peter koch]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ralconstant-expression&quot ; to &quot;integr al expression&quot ;

On 24 Okt., 23:56, CBFalconer <cbfalco...@yah oo.comwrote:

anon wrote:
>
... snip ...
>

There is something wrong. Try to compile this example, and I hope
you figure whats wrong with his proposal :

>

int main()
{
     int a = 3;
     switch( a )
     {
         case 3:
             a = 1;
             break;
         case 3:
             a = 2;
             break;
         case 3:
             a = 3;
             break;
         default:
             a = 4;
     }
}

>
Your code works better if it is made legal:
>
int main(void) {
     int a = 3;
>
     switch( a ) {
case 3:  a = 1;
         break;
case 2:  a = 2;
         break;
case 1:  a = 3;
         break;
default: a = 4;
     }
     return 0;
>
}

The original code would be legal: case-labels would not be required to
be unique in that proposal, and all the "encased" statements except
for the first label would basically be dead.

>
Also, cross posting to c.l.c++ is not cool.

This is one of the cases where it would be: The proposal is for both C
and C++. Hopefully the proposal will be rejected equally unanimously
both places ;-)

/Peter

[vippstar@gmail.com]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ralconstant-expression&quot ; to &quot;integr al expression&quot ;

On Oct 25, 12:56 am, CBFalconer <cbfalco...@yah oo.comwrote:

anon wrote:
>
... snip ...
>

There is something wrong. Try to compile this example, and I hope
you figure whats wrong with his proposal :

>

int main()
{
int a = 3;
switch( a )
{
case 3:
a = 1;
break;
case 3:
a = 2;
break;
case 3:
a = 3;
break;
default:
a = 4;
}
}

>
Your code works better if it is made legal:
>
int main(void) {
int a = 3;
>
switch( a ) {
case 3: a = 1;
break;
case 2: a = 2;
break;
case 1: a = 3;
break;
default: a = 4;
}
return 0;
>
}

His code _is_ legal under C99.

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

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ralconstant-expression&quot ; to &quot;integr al expression&quot ;

On Sat, 25 Oct 2008 04:07:27 -0700, vippstar wrote:

On Oct 25, 12:56 am, CBFalconer <cbfalco...@yah oo.comwrote:

>anon wrote:
>>
>... snip ...
>>

There is something wrong. Try to compile this example, and I hope you
figure whats wrong with his proposal :

>>

int main()
{
int a = 3;
switch( a )
{
case 3:
a = 1;
break;
case 3:
a = 2;
break;
case 3:
a = 3;
break;
default:
a = 4;
}
}

>>
>Your code works better if it is made legal:

>
His code _is_ legal under C99.

No, it's not, and intentionally so. 6.8.4.2p3:
"The expression of each case label shall be an integer constant expression
and no two of the case constant expressions in the same switch statement
shall have the same value after conversion. [...]"

Do you have any compiler that accepts the code? If so, what does it set a
to?

[Jeff Schwab]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Adem wrote:

C/C++ language proposal:
Change the 'case expression' from "integral constant-expression" to "integral expression"
>
The C++ Standard (ISO/IEC 14882, Second edition, 2003-10-15)
says under 6.4.2(2) [see also 5.19]:
>
case constant-expression :
>
I propose that the case expression of the switch statement
be changed from "integral constant-expression" to "integral expression".
This opens up many new possibilities since then also function calls
would be permitted in the case expression.

In what way would your altered switch be superior to an if/else tree?

The primary reason to use a switch is that it may be translated at
compile-time into a jump table, but that benefit goes away if the
statements are not known until run-time. Languages like Ruby have
switches with run-time case expressions because they delay the
translation until run-time, anyway; such languages are using the syntax
to mean something very different from what the C switch means. IOW,
languages that provide case statements of the form you've suggested do
so only because they *can't* do what C and C++ do.

[Jerry Coffin]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

In article <gdqf6p$fqj$1@a ioe.org>, for-usenet-5c@alicewho.com says...

[ ... ]

int y, x = f();
switch (x)
{
case 123 : y = g(); break;
case g() : y = 456; break; // using new case feature, ie. func-call
case h() : y = 789; break; // ditto
default : y = -1; break;
}

This has a number of ramifications that could make definition difficult.
For a few examples, how often would g() be evaluated in the switch
statement above? If both g() and h() returned the same value, which leg
would be taken?

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Jerry Coffin <jcoffin@taeus. comwrites:

In article <gdqf6p$fqj$1@a ioe.org>, for-usenet-5c@alicewho.com says...
>
[ ... ]
>

>int y, x = f();
>switch (x)
> {
> case 123 : y = g(); break;
> case g() : y = 456; break; // using new case feature, ie. func-call
> case h() : y = 789; break; // ditto
> default : y = -1; break;
> }

>
This has a number of ramifications that could make definition difficult.
For a few examples, how often would g() be evaluated in the switch
statement above? If both g() and h() returned the same value, which leg
would be taken?

The person proposing the feature did not give enough information to
answer those questions. If the proposed feature were to be added to
the language, then the semantics would have to be worked out first;
doing so shouldn't be too difficult. Once that's done, the answers to
your questions become obvious rather than indeterminate. (Possibly in
some cases the execution would be implementation-defined, or
unspecified, or even undefined, but I'd prefer a simpler definition
that avoids that.)

In my preferred semantics, the above would be exactly equivalent to:

int y, x = f();
int __tmp = x;
if (__tmp == 123) y = g();
else if (__tmp == g()) y = 456;
else if (__tmp == h()) y = 789;
else y = -1;

The number of times g() is evaluated depends on the value of x and the
value returned by g(), which you haven't specified. If both g() and
h() return the same value, and that happens to be the value of x, then
y would be set to 456.

But, as I said, I think the whole thing is a bad idea.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Matthias Buelow]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integralc onstant-expression&quot ; to &quot;integr al expression&quot ;

Adem wrote:

C/C++ language proposal:
Change the 'case expression' from "integral constant-expression" to "integral expression"

How about:

cond {
(foo == bar): ...; break;
(!bar && (baz == boo)): ...; /* fallthru */
default: ...; break;
}

In pseudo-grammar:

cond { [<expr>|defaul t: <stmt>*]* }

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Matthias Buelow <mkb@incubus.de writes:

Adem wrote:

>C/C++ language proposal:
> Change the 'case expression' from "integral constant-expression"
> to "integral expression"

>
How about:
>
cond {
(foo == bar): ...; break;
(!bar && (baz == boo)): ...; /* fallthru */
default: ...; break;
}
>
In pseudo-grammar:
>
cond { [<expr>|defaul t: <stmt>*]* }

One advantage of the switch statement is that the expression only has
to be written once; it's implicitly compared to each of the case label
expressions without being re-evaluated.

Your proposed "cond" statement lacks this advantage, and differs from
an if/else chain only in the ability to fall through from one case to
the next. The latter can easily be done with a goto statement. (Yes,
gotos are ugly; so is falling through from one case to the next. And
you can always restructure the code to avoid gotos.)

As for the grammar, I think you'd want to require a keyword, probably
"case", for each expression:

cond {
case foo == bar: ... break;
case !bar && (baz == boo): ...; /* fallthrough */
default: ...; break;
}

Otherwise the compiler doesn't know until it sees the ':' whether the
expression is part of the cond statement or just an ordinary
expression statement.

And of course it would break every existing program that uses "cond"
as a keyword, but that's easily solved by using "_Cond".

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark L Pappin]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Keith Thompson <kst-u@mib.orgwrites :

And of course it would break every existing program that uses "cond"
as a keyword,

ITYM "as an identifier,".

mlp

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

Mark L Pappin <mlp@acm.orgwri tes:

Keith Thompson <kst-u@mib.orgwrites :

>And of course it would break every existing program that uses "cond"
>as a keyword,

>
ITYM "as an identifier,".

D'oh! Yes, thanks.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[JoelKatz]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ral constant-expression&quot ; to &quot;integr al expression&quot ;

On Oct 25, 10:43 am, Jeff Schwab <j...@schwabcen ter.comwrote:

In what way would your altered switch be superior to an if/else tree?

Two ways:

1) An if/else tree hides the fact that the same variable is being
tested in each branch. A switch/case makes it clear that the same
expression is being compared in each case.

2) In some cases, it would make truly atrocious code look better. For
example, consider cases where you need to fall through from one case
to another or where you would otherwise need a temporary to avoid
multiple evaluations of the switch variable.

The primary reason to use a switch is that it may be translated at
compile-time into a jump table, but that benefit goes away if the
statements are not known until run-time.  Languages like Ruby have
switches with run-time case expressions because they delay the
translation until run-time, anyway; such languages are using the syntax
to mean something very different from what the C switch means.  IOW,
languages that provide case statements of the form you've suggested do
so only because they *can't* do what C and C++ do.

But they don't provide what he's asking for, and it's a natural
extension of the semantics of the switch/case statement. We could have
a special 'if' that allowed the implementation to cycle a specified
constant, either by counting up, down, or sideways if that was most
efficient. But we don't. We expect the optimizer to figure out how our
code can be micro-optimized.

Why do we have do/while, while, and for? You can make any code ugly by
choosing the wrong one, but you can make a lot of code nice by
choosing the best one.

The biggest argument against this proposal is that it's not really all
that useful. There really just aren't that many places where you could
use something like this.

In a 500,000 C++ line project I'm very familiar with, there are three
places where this could actually be useful. For comparison, it has 818
switch statements.

In two of those cases, it cleans up some ugliness where you need an if/
else tree before a switch/case statement.

What will be next? "case >=7:"?

DS

[James Kanze]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ral constant-expression&quot ; to &quot;integr al expression&quot ;

On Oct 28, 7:24 pm, Matthias Buelow <m...@incubus.d ewrote:

Adem wrote:

C/C++ language proposal:
Change the 'case expression' from "integral
constant-expression" to "integral expression"

How about:

cond {
(foo == bar): ...; break;
(!bar && (baz == boo)): ...; /* fallthru */
default: ...; break;
}

In pseudo-grammar:

cond { [<expr>|defaul t: <stmt>*]* }

I once designed a language with something like that, many, many
years back. In fact, the grammar was a bit more complete,
something like:

cond_stmt := 'cond' [<expr1>] '{' case_list '}'
case_list := /* empty */ | case_list case_clause
case_clause := 'case' [<op>] expr2 ':' stmt
| 'default' ':' stmt

If expr1 was absent, <opwas forbidden, and it worked exactly
like your suggestion (except that there was no fall through---a
case controlled exactly one statement). If expr1 was present,
it was the equivalent of having written "case <expr1<op>
<expr2>" for each case, except that expr1 was only evaluated
once; if you omitted the <opin this case, it defaulted to ==,
so you could write things like:

cond x {
case 0 : ... ;
case == 0 : ... ;
case < 0 : ... ;
}

or

cond c {
case 'a' : ... ;
case 'b' : ... ;
case 'c' : ... ;
}

(IIRC, the keyword was actually select, and not cond, and I used
OF .. END instead of {..}. But the basic idea was the same.)

The idea was basically that there are only four basic structured
constructs: a loop, a choice, a sequence, and a procedure call,
and thus, there were only four basic execution statements.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[robertwessel2@yahoo.com]

Re: C/C++ language proposal: Change the 'case expression' from&quot;integ ral constant-expression&quot ; to &quot;integr al expression&quot ;

On Oct 28, 7:42 pm, JoelKatz <dav...@webmast er.comwrote:

What will be next? "case >=7:"?

Frankly I think ranges on the case constant expressions would be a
more useful addition while staying with the basic philosophy of the C
switch statement. IOW, "case 2...5:", or something along those
lines. But still not something I'm loosing sleep over...

[Keith Thompson]

Re: C/C++ language proposal: Change the 'case expression' from &quot;integr al constant-expression&quot ; to &quot;integr al expression&quot ;

"robertwessel2@ yahoo.com" <robertwessel2@ yahoo.comwrites :

On Oct 28, 7:42 pm, JoelKatz <dav...@webmast er.comwrote:

>What will be next? "case >=7:"?

>
Frankly I think ranges on the case constant expressions would be a
more useful addition while staying with the basic philosophy of the C
switch statement. IOW, "case 2...5:", or something along those
lines. But still not something I'm loosing sleep over...

Then programmers will inevitably write

case 'A' ... 'Z':

which is non-portable (under EBCDIC it matches '\' and '}').

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"