«

I've always been bothered by the restriction that case statements must
have constant integer values for their case expressions. That is, the
following is impossible:

int x = 10, y = 10;
switch(x) {
case y:
System.out.println("y=10");
break;
default:
System.out.println("y!=10");
break;
}

I could very easily turn that into cascading if statements:

int x = 10, y = 10;
if(x == y) {
System.out.println("y=10");
}
else {
System.out.println("y!=10");
}

So what is it about a switch statement that requires this restriction?
I would hope that there is some optimization or other advantage to
compensate for this disadvantage (really a pain when doing type-safe
enums, but hopefully JDK 1.5 will make that a moot point).

A VB programmer (yes, VB) once suggested that the compiler could
relate incoming values to instruction locations so that it wouldn't
have to test each value but merely jump directly to the location
needed. I tend to think that would be impossible since the incoming
value could take on any value.

Can someone enlighten me?

Regards,
Brian.

On 2 Jul 2003 06:31:58 -0700, (Brian J. Sayatovic) wrote
or quoted :

>
>So what is it about a switch statement that requires this restriction?

Laziness on the part of the compiler writers/language designers. When
the switch constants are variables, the switch has to be implemented
differently than when you know all the values at compile time.

When the values are known at compile time and don't change, you can
compose a jump table, i.e. a array of addresses of code to execute.

With a tiny bit more ambition on the part of compiler writers, ranges
too could also be handled much more efficiently than typically hand
coded nested ifs.

See http://mindprod.com/projcasefixer.html
http://mindprod.com/projcaserange.html
http://mindprod.coom/bali.html#EXTENDEDCASE

--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.

Roedy Green wrote:
> On 2 Jul 2003 06:31:58 -0700, (Brian J. Sayatovic) wrote
> or quoted :
>
>
>>So what is it about a switch statement that requires this restriction?
>
>
> Laziness on the part of the compiler writers/language designers. When
> the switch constants are variables, the switch has to be implemented
> differently than when you know all the values at compile time.
>
> When the values are known at compile time and don't change, you can
> compose a jump table, i.e. a array of addresses of code to execute.

Which ought to perform better than a series of ifs. I personally have
no objection to having to write things in if form when I am testing
against variable alternatives.

> With a tiny bit more ambition on the part of compiler writers, ranges
> too could also be handled much more efficiently than typically hand
> coded nested ifs.

That is a feature I would love to have. (And it has been available in
Fortran since Fortran-90, BTW. I don't know how Sun lives with itself,
knowing that Java is trailing behind Fortran. )


John Bollinger

Brian J. Sayatovic wrote:
> I've always been bothered by the restriction that case statements must
> have constant integer values for their case expressions.
> So what is it about a switch statement that requires this restriction?
> I would hope that there is some optimization or other advantage to
> compensate for this disadvantage (really a pain when doing type-safe
> enums, but hopefully JDK 1.5 will make that a moot point).
>
> A VB programmer (yes, VB) once suggested that the compiler could
> relate incoming values to instruction locations so that it wouldn't
> have to test each value but merely jump directly to the location
> needed. I tend to think that would be impossible since the incoming
> value could take on any value.

There are two byte code instructions to do switchs, lookupswitch (which
has a table of value/offset pairs) and tableswitch (which has just a
jumptable). The compiler uses one or the other depending on the shape of
the values on the case statements.

(Brian J. Sayatovic) wrote:
> I've always been bothered by the restriction that case statements must
> have constant integer values for their case expressions.
> [snip]
> So what is it about a switch statement that requires this restriction?

James Gosling is the person who knows why Java was designed the way
that it was. I've never seen him post to the Usenet Java groups.
Anyone here can only guess.

> I would hope that there is some optimization or other advantage to
> compensate for this disadvantage

The bytecodes for handling switches -- tableswitch and lookupswitch --
require integer values. Anything else would have to be turned into an
if/elseif by the compiler.

(Brian J. Sayatovic) wrote:

>I've always been bothered by the restriction that case statements must
>have constant integer values for their case expressions. That is, the
>following is impossible:
>
>int x = 10, y = 10;
>switch(x) {
> case y:
> System.out.println("y=10");
> break;
> default:
> System.out.println("y!=10");
> break;
>}
>
>I could very easily turn that into cascading if statements:
>
>int x = 10, y = 10;
>if(x == y) {
> System.out.println("y=10");
>}
>else {
> System.out.println("y!=10");
>}

You've already gotten some answers about how the compiler can optimize the
switch if the values are known at compile time.

In an object-oriented language, a large cascading if structure is often a
sign of a poor design.

I'd suggest that for values which aren't known 'til run time, see if you can
use a HashMap or something similar to solve your problem. Change it back to
cascading ifs only if performance testing dictates such after you have
finished implementing.

"John C. Bollinger" <>, Wed, 02 Jul 2003 09:56:26
-0500:

> Roedy Green wrote:
>> On 2 Jul 2003 06:31:58 -0700, (Brian J. Sayatovic) wrote
>> or quoted :

>> With a tiny bit more ambition on the part of compiler writers, ranges
>> too could also be handled much more efficiently than typically hand
>> coded nested ifs.
>
> That is a feature I would love to have. (And it has been available in
> Fortran since Fortran-90, BTW. I don't know how Sun lives with itself,
> knowing that Java is trailing behind Fortran. )

It would save some typing I guess. Does Fortran do things like the
EVALUATE in COBOL?

EVALUATE x ALSO y ALSO z ALSO TRUE
WHEN 1 ALSO 2 ALSO 3 THRU 10 ALSO fun
PERFORM haha
WHEN 2 ALSO 3 ALSO 11 THRU 12 ALSO fun
PERFORM hahaha
END-EVALUATE

Haven't seen anything like this in any other other language.

Bhun.

dhek bhun kho wrote:
> "John C. Bollinger" <>, Wed, 02 Jul 2003 09:56:26
> -0500:
>
>
>>Roedy Green wrote:
>>>With a tiny bit more ambition on the part of compiler writers, ranges
>>>too could also be handled much more efficiently than typically hand
>>>coded nested ifs.
>>
>>That is a feature I would love to have. (And it has been available in
>>Fortran since Fortran-90, BTW. I don't know how Sun lives with itself,
>>knowing that Java is trailing behind Fortran. )
>
>
> It would save some typing I guess. Does Fortran do things like the
> EVALUATE in COBOL?
>
> EVALUATE x ALSO y ALSO z ALSO TRUE
> WHEN 1 ALSO 2 ALSO 3 THRU 10 ALSO fun
> PERFORM haha
> WHEN 2 ALSO 3 ALSO 11 THRU 12 ALSO fun
> PERFORM hahaha
> END-EVALUATE
>
> Haven't seen anything like this in any other other language.

Fortran's version is structurally more like C and Java. Example:

select case (foo)
case (:-1)
do stuff
case (0, 2, 4, 6:57)
do something else
case default
do something different
end select

The Fortran version has no fall-through. It supports a very flexible
and IMO intuitive syntax including open- and closed-ended value ranges
and sequences of values and value ranges. It also supports character
case values (the Fortran analogue of Java Strings) but not mixed with
integer case values or selection expressions. I think it would be a
inappropriate for Java to tie the String class to a control construct,
but it sure would be convenient to have something similar to the Fortran
flavor of expressing case values.

But lest we miss an important point, do I understand that Java is also
lagging behind COBOL?!?


John Bollinger

Hello John,

"John C. Bollinger" <>, Wed, 02 Jul 2003 16:47:28
-0500:

> dhek bhun kho wrote:
>> "John C. Bollinger" <>, Wed, 02 Jul 2003 09:56:26
>> -0500:
>>>Roedy Green wrote:
>>>>With a tiny bit more ambition on the part of compiler writers, ranges
>>>>too could also be handled much more efficiently than typically hand
>>>>coded nested ifs.
>>>
>>>That is a feature I would love to have. (And it has been available in
>>>Fortran since Fortran-90, BTW. I don't know how Sun lives with itself,
>>>knowing that Java is trailing behind Fortran. )
>>
>> It would save some typing I guess. Does Fortran do things like the
>> EVALUATE in COBOL?
>>
>> EVALUATE x ALSO y ALSO z ALSO TRUE
>> WHEN 1 ALSO 2 ALSO 3 THRU 10 ALSO fun
>> PERFORM haha
>> WHEN 2 ALSO 3 ALSO 11 THRU 12 ALSO fun
>> PERFORM hahaha
>> END-EVALUATE
>>
>> Haven't seen anything like this in any other other language.
>
> Fortran's version is structurally more like C and Java. Example:
>
> select case (foo)
> case (:-1)
> do stuff
> case (0, 2, 4, 6:57)
> do something else
> case default
> do something different
> end select
>
> The Fortran version has no fall-through. It supports a very flexible

Sorry, I do not understand what you mean with fall-through. (Not a native
speaker).

> and IMO intuitive syntax including open- and closed-ended value ranges
> and sequences of values and value ranges. It also supports character
> case values (the Fortran analogue of Java Strings) but not mixed with
> integer case values or selection expressions. I think it would be a
> inappropriate for Java to tie the String class to a control construct,

Isn't this related to the fact that although two Strings might have the
same content, they are not always equal? (Unless you make sure they are
always internalized).

I do find it a loss, that Java does not support ranges (eg.
Modula-2) or enumerations. You can always code it as a
separate class, but it's awkward.

> but it sure would be convenient to have something similar to the Fortran
> flavor of expressing case values.

Is anything like this coming up in the 1.5 release?

> But lest we miss an important point, do I understand that Java is also
> lagging behind COBOL?!?
>

Hahaha. YES! Just kidding. I like Java, while it is not the end of the
world or anything, it's a nuisance to keep typing thing like MOVE ADD
CALCULATE and such.

What I liked about COBOL was how easy it is to do file operations. Yes,
they are platform dependent, but coding a persistent data structure was
almost trivial in COBOL. I have not seen any COBOL-2000 code though.

I find it odd that there are no standard facilities for easy persistence
with low memory usage. Everything is serial(!). As soon I want to perform
random access, I have to code every detail; or resort to a database
solution. (I am not coding any application creating 2e6 application). The
other solution would be read the whole file into memory, but that's like
swatting a fly with a sledge hammer.

It seems a lot easier to write the persistence code in COBOL, write some
JNI wrappers and call it from Java. I would not want to code an user
interface in COBOL.

> John Bollinger
>

Greets.
Bhun.

U¿ytkownik napisa³:
> In an object-oriented language, a large cascading if structure is often a
> sign of a poor design.
>
> I'd suggest that for values which aren't known 'til run time, see if you can
> use a HashMap or something similar to solve your problem. Change it back to
> cascading ifs only if performance testing dictates such after you have
> finished implementing.

Even better - try to use inheritance and polymorphism.
--
Ecce Jezuch
"Science has failed our world
Science has failed our mother Earth" - S. Tankian