🚀 go-pugleaf

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 <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

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

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