There seems to be a fundamental reason why case/switch statements
with variable/expression tags are to be avoided and that is the
impossibility of guaranteeing that a unique tag will be selected.
This means that either some ordering of tag interrogation has to
be imposed which will kill optimisations (unless all tags are constant)
or we abandon determinism and let the compiler decide.  Of course
this construct has been discussed before by Hoare,  I seem to
remember something about programs shouldn't depend on the order
of guard evaluation.  Even worse in parallel processing two guards
may get evaluated to true so parallel languages like Occam must
do something about this, but I don't know what.

In article <9907@rice-chex.ai.mit.edu> rpk@rice-chex.ai.mit.edu (Robert Krajewski) writes:
> In article <962@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
> >I disagree.  A series of 'if' statements implies a sequence of tests
> >to be performed.  A 'switch' implies a multi-way branch in which any
> >of the possible case values are equally likely to occur.  This can
> >be easily optimized by a compiler.  Although the standard does not
> >mandate it, a switch statement is expected, in most cases, to be
> >implemented as a quick indirect-jump table.
>
> Let the compiler decide that, then. switch should just specify
> semantics.

Exactly. A resonable compiler will compile a switch with two or three cases
as an if/then/else sequence, internally. Often compilers also break up
switches with large gaps between tag values.

> >It is not unusual to have switches with over 100 cases which would
> >not perform acceptably as a series of 'if' statements.  Syntactical
> >sugar indeed!
>
> Well, there is one other benefit to switch: the switched thing is
> an expression, it is evaluated only once, right ?  So you get a
> temporary for free if you need it.
>
> I would like to see switch be extended at least to cover data types
> for which == holds.  It's unfortunate that case tags have to be constants,
> but I can live with that.

The problem here is that the compiler has no guarantee that a user-defined
operator== provides the nice mathematical properties of true equality. For
all the compiler knows, for a user-defined type T, "a==b && b==c" does not
necessarily imply "a==c"; in fact it doesn't even guarantee "b==a". Yes, it's
bad coding to violate these expected properties, but a compiler can't rely
on "good form", only on the language standard.

Thus, you'd have to carefully define whether
 switch (x) { case a: mumble(); }
means
 if (x==a) mumble();
or
 if (a==x) mumble();
Neither interpretation strikes me as inherently more obvious. You don't really
want to add this kind of confusion to the language.


  About non-constant case tags:

The main problem with allowing non-constant case tags is precisely that the
"switch" statement is intended as a "simultaneous choice" operation, not
a sequential scan. Consider this example:

 switch (expr) {
 case foo(): mumble(); break;
 case bar(): tumble(); break;
 }

How are foo() and bar() evaluated? Both, before a choice is made? In what
order? If you *require* both foo() and bar() to be always evaluated, the
compiler can't short-circuit things if it finds an early match, so the result
would never be more efficient than an if-cascade. And what happens if foo()
and bar() evaluate to the same value? Execute mumble() or tumble(), or both()
(in what order :-)? This isn't a can of worms, it's a whole truck load.
If you want a good laugh, try to interprete this:

 switch (n) {
 case n++: n--; mad(); break;
 case n++: n--; ness(); break;
 }

Just to beat the dead horse into pulp, imagine that expr (and foo and bar)
above are of a user-defined type with an operator== defined. Now the compiler
is completely clue-less. It is possible that "expr==foo() && expr==bar()"
but "foo() != bar()". To give well-defined semantics to this construct, we
would have to rigidly define one particular order of evaluation for things.
And that would indeed reduce this new construct to purely syntactic sugar on
top of an if/then/else cascade.
  -- perry

P.S.: If your main concern is the visual ugliness and confusion of long
 if-cascades, you can use the preprocessor to make your own syntax.
 I'm not sure that I would recomment that, though.
--
--------------------------------------------------------------------------
Perry The Cynic (Peter Kiehtreiber)         perry@arkon.key.com
** What good signature isn't taken yet? **  {amdahl,sgi,pacbell}!key!perry

In article <26842@pasteur.Berkeley.EDU> krste@ICSI.Berkeley.EDU ( Krste Asanovic) writes:
>The C/C++ switch statement is very limited as it only allows integer
>expressions. I'd like to suggest a more general case statement.
>The syntax would be,
>
>    case (exp) {
>        case val1 : s1;
>        case val2 : s2;
>        default : sOther;
>    }
>
> ...

I think this is unnecessary. C++ is already a large language and new
features which don't have important semantic advantages should
be avoided. The case statement you mention above would only add
type checking and non compile time constants "switched" on in a (I
presume) syntactically pleasing way. This does not warrant
extending the language when you can do the semantic equivalent as
easily as:

    if (exp == val1)
 s1
    else if (exp == val2)
 s2
    else if (exp == val3 || exp == val4 || exp == val5 || ...)
 s3
    ...

----------------------------------------------------------
 Jeff Bilmes        arpa: bilmes@icsi.berkeley.edu
                    uucp: ...!ucbvax!icsi!bilmes

The C/C++ switch statement is very limited as it only allows integer
expressions. I'd like to suggest a more general case statement.
The syntax would be,

    case (exp) {
        case val1 : s1;
        case val2 : s2;
        default : sOther;
    }

This uses the already reserved keyword case, followed by a
parenthesised expression, to introduce the construct. The standard
switch case and default labels would be used as before. The limitation
that case label expressions are compile-time constants would be
removed (although optimizing compilers could check for this case). The
limitation that case labels be unique would be removed (can't check
this at run time), but the order in which case expressions were tested
would be undefined. Comparisions would use the appropriate ==
operator, in the above example the tests would be

if (exp.operator==(val1)) ..s1...   \ in undefined order.
if (exp.operator==(val2)) ..s2...   /

In article <26842@pasteur.Berkeley.EDU> krste@ICSI.Berkeley.EDU ( Krste Asanovic) writes:
>The C/C++ switch statement is very limited as it only allows integer
>expressions. I'd like to suggest a more general case statement.
>The syntax would be,
>
>    case (exp) {
>        case val1 : s1;
>        case val2 : s2;
>        default : sOther;
>    }

Try this, which is already legal C++:

 if (exp == val1)
  s1;
 else if (exp == val2)
  s2;
 else
  sOther;

It is a bit less convenient to type, but does the job.  I greatly doubt
that X3J16 will sanction a new and untried feature which duplicates
an existing one with only a trivial variation in syntax.
--
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry

In article <26857@pasteur.Berkeley.EDU> bilmes@icsib (Jeff Bilmes) writes:
>In article <26842@pasteur.Berkeley.EDU> krste@ICSI.Berkeley.EDU ( Krste Asanovic) writes:
>>The C/C++ switch statement is very limited as it only allows integer
>>expressions.
...
>
>This does not warrant
>extending the language when you can do the semantic equivalent as
>easily as:
>
>    if (exp == val1)
> s1
>    else if (exp == val2)
> s2
>    else if (exp == val3 || exp == val4 || exp == val5 || ...)
> s3
>    ...

By this logic, switch statements should not have been invented
in the first place.  Clearly in C a need was felt for this syntactic
sugar.  Krste was merely pointing out that one can argue that
the same needs can motivate a similar extension for non-integral
types, of which there are a significantly larger number in C++
(that have equality operators) than in C.

I guess I don't feel particularly strongly about this issue;
I just felt the reasoning being used was flawed.


 Bob Atkinson
 Microsoft

In article <56515@microsoft.UUCP> bobatk@microsoft.UUCP (Bob ATKINSON) writes:
>In article <26857@pasteur.Berkeley.EDU> bilmes@icsib (Jeff Bilmes) writes:
>>This does not warrant
>>extending the language when you can do the semantic equivalent as
>>easily as:
>>
>>    if (exp == val1)
>> s1
>>    else if (exp == val2)
>> s2
>>    else if (exp == val3 || exp == val4 || exp == val5 || ...)
>> s3
>>    ...
>
>By this logic, switch statements should not have been invented
>in the first place.  Clearly in C a need was felt for this syntactic
>sugar....

I disagree.  A series of 'if' statements implies a sequence of tests
to be performed.  A 'switch' implies a multi-way branch in which any
of the possible case values are equally likely to occur.  This can
be easily optimized by a compiler.  Although the standard does not
mandate it, a switch statement is expected, in most cases, to be
implemented as a quick indirect-jump table.

It is not unusual to have switches with over 100 cases which would
not perform acceptably as a series of 'if' statements.  Syntactical
sugar indeed!

It is difficult to expand the multiway-jump concept to include
non-integral values.  In those cases, a switch statement really is
nothing more than a series of 'if's.

--
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott

bobatk@microsoft.UUCP (Bob ATKINSON) writes:
>bilmes@icsib (Jeff Bilmes) writes:
>>krste@ICSI.Berkeley.EDU ( Krste Asanovic) writes:
>>>The C/C++ switch statement is very limited as it only allows integer
>>>expressions.
>...
>>
>>This does not warrant
>>extending the language when you can do the semantic equivalent as
>>easily as:
>>
>>    if (exp == val1)
>> s1
>>    else if (exp == val2)
>> s2
>>    else if (exp == val3 || exp == val4 || exp == val5 || ...)
>> s3
>>    ...
>
>By this logic, switch statements should not have been invented
>in the first place.  Clearly in C a need was felt for this syntactic
>sugar.  Krste was merely pointing out that one can argue that
>the same needs can motivate a similar extension for non-integral
>types, of which there are a significantly larger number in C++
>(that have equality operators) than in C.
>
>I guess I don't feel particularly strongly about this issue;
>I just felt the reasoning being used was flawed.

Perhaps, but there is a more important reason to leave things alone:
there are well known problems with testing equality with, explicitly,
floating point values, and an extension of the case statement, where
the test is unobvious, to allow, explicitly, floating point case
switches, would promote maintenance problems.

When the test is done with the "else if" paradigm, the use of the
equality test is explicit, obvious, and thus easier to spot as a
possible source of trouble during maintenance.

Just a thought.

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>

In article <962@bbxsda.UUCP> scott@bbxsda.UUCP (Scott Amspoker) writes:
>I disagree.  A series of 'if' statements implies a sequence of tests
>to be performed.  A 'switch' implies a multi-way branch in which any
>of the possible case values are equally likely to occur.  This can
>be easily optimized by a compiler.  Although the standard does not
>mandate it, a switch statement is expected, in most cases, to be
>implemented as a quick indirect-jump table.

Let the compiler decide that, then. switch should just specify
semantics.

>It is not unusual to have switches with over 100 cases which would
>not perform acceptably as a series of 'if' statements.  Syntactical
>sugar indeed!

Well, there is one other benefit to switch: the switched thing is
an expression, it is evaluated only once, right ?  So you get a
temporary for free if you need it.

I would like to see switch be extended at least to cover data types
for which == holds.  It's unfortunate that case tags have to be constants,
but I can live with that.
--
Robert P. Krajewski
Internet: rpk@ai.mit.edu ; Lotus: robert_krajewski.lotus@crd.dnet.lotus.com