Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Why constant ints in switch case expressions?

Reply
Thread Tools

Why constant ints in switch case expressions?

 
 
Brian J. Sayatovic
Guest
Posts: n/a
 
      07-02-2003
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.
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      07-02-2003
On 2 Jul 2003 06:31:58 -0700, http://www.velocityreviews.com/forums/(E-Mail Removed) (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.
 
Reply With Quote
 
 
 
 
John C. Bollinger
Guest
Posts: n/a
 
      07-02-2003
Roedy Green wrote:
> On 2 Jul 2003 06:31:58 -0700, (E-Mail Removed) (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
(E-Mail Removed)

 
Reply With Quote
 
David Zimmerman
Guest
Posts: n/a
 
      07-02-2003


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.

 
Reply With Quote
 
Doug Pardee
Guest
Posts: n/a
 
      07-02-2003
(E-Mail Removed) (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.
 
Reply With Quote
 
brougham3@yahoo.com
Guest
Posts: n/a
 
      07-02-2003
(E-Mail Removed) (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.
 
Reply With Quote
 
dhek bhun kho
Guest
Posts: n/a
 
      07-02-2003
"John C. Bollinger" <(E-Mail Removed)>, Wed, 02 Jul 2003 09:56:26
-0500:

> Roedy Green wrote:
>> On 2 Jul 2003 06:31:58 -0700, (E-Mail Removed) (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.

 
Reply With Quote
 
John C. Bollinger
Guest
Posts: n/a
 
      07-02-2003
dhek bhun kho wrote:
> "John C. Bollinger" <(E-Mail Removed)>, 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
(E-Mail Removed)

 
Reply With Quote
 
dhek bhun kho
Guest
Posts: n/a
 
      07-02-2003
Hello John,

"John C. Bollinger" <(E-Mail Removed)>, Wed, 02 Jul 2003 16:47:28
-0500:

> dhek bhun kho wrote:
>> "John C. Bollinger" <(E-Mail Removed)>, 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
> (E-Mail Removed)


Greets.
Bhun.
 
Reply With Quote
 
Jezuch
Guest
Posts: n/a
 
      07-02-2003
Użytkownik (E-Mail Removed) 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"error C2057: expected constant expression", "error C2466: cannot allocate an array of constant size 0". Why doesn't my simple program work??? hn.ft.pris@gmail.com C++ 13 01-22-2007 02:03 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Iterator Question for map of ints to set of ints uclamathguy@gmail.com C++ 3 04-03-2005 03:26 AM
ints ints ints and ints Skybuck Flying C Programming 24 07-10-2004 04:48 AM
Re: C - switch case label refuses a constant int pete C Programming 2 09-14-2003 06:06 AM



Advertisments