Why constant ints in switch case expressions?

Discussion in 'Java' started by Brian J. Sayatovic, Jul 2, 2003.

  1. 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.
    Brian J. Sayatovic, Jul 2, 2003
    #1
    1. Advertising

  2. Brian J. Sayatovic

    Roedy Green Guest

    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, Jul 2, 2003
    #2
    1. Advertising

  3. 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
    John C. Bollinger, Jul 2, 2003
    #3
  4. 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.
    David Zimmerman, Jul 2, 2003
    #4
  5. Brian J. Sayatovic

    Doug Pardee Guest

    (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.
    Doug Pardee, Jul 2, 2003
    #5
  6. Brian J. Sayatovic

    Guest

    (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.
    , Jul 2, 2003
    #6
  7. "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, Jul 2, 2003
    #7
  8. 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
    John C. Bollinger, Jul 2, 2003
    #8
  9. 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.
    dhek bhun kho, Jul 2, 2003
    #9
  10. Brian J. Sayatovic

    Jezuch Guest

    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
    Jezuch, Jul 3, 2003
    #10
  11. dhek bhun kho <> scribbled the following:
    > 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).


    Fall-through means that when a matching case is found, that case *AND*
    all cases after it are executed. Compare Pascal:

    case (a) of
    1: println('Foo');
    2: println('Bar');
    end;

    with C:

    switch (a) {
    case 1: printf("Foo\n");
    case 2: printf("Bar\n");
    }

    Suppose a has the value 1. The Pascal version will only print "Foo" but
    the C version will print both "Foo" and "Bar". If a has the value 2 both
    Pascal and C will only print "Bar".
    Java works like C, i.e. it has the fall-through.

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


    They are not equal in the sense that they are not the same object, but
    equals() will still consider them equal.

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


    Isn't the whole idea of object orientation that you can always code a
    class for anything?

    (snip about COBOL)

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "Shh! The maestro is decomposing!"
    - Gary Larson
    Joona I Palaste, Jul 3, 2003
    #11
  12. Certainly, but that was not the point.

    rkm <> wrote in message news:<>...
    > 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]

    > doesn't it seem obvious that with your idea you could code
    > this indeterminant bit of code?
    Brian J. Sayatovic, Jul 3, 2003
    #12
  13. Brian J. Sayatovic

    Tim Tyler Guest

    rkm <> wrote:
    : Brian J. Sayatovic wrote:
    :> I've always been bothered by the restriction that case statements must
    :> have constant integer values for their case expressions. [...]

    : doesn't it seem obvious that with your idea you could code
    : this indeterminant bit of code?

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

    : Hmmm, where would it go, to case x or case y?

    case x.
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Jul 3, 2003
    #13
  14. Brian J. Sayatovic

    rkm Guest

    You asked "So what is it about a switch statement that
    requires this restriction?", and I think I'm the only one
    that came up with a valid reason why you shouldn't be able
    to do what you asked. Others either agreed with you or
    declared it was because compiler writers are lazy. I think
    they missed the point.

    Rick


    Brian J. Sayatovic wrote:
    > Certainly, but that was not the point.
    >
    > rkm <> wrote in message news:<>...
    >
    >>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]
    >
    >
    >>doesn't it seem obvious that with your idea you could code
    >>this indeterminant bit of code?

    >
    rkm, Jul 3, 2003
    #14
  15. "rkm" <> wrote in message
    news:...
    > 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;
    > > }
    > >

    >
    > doesn't it seem obvious that with your idea you could code
    > this indeterminant bit of code?
    >
    >
    > int x = 10, y = 10;
    > switch(x)
    > {
    > case x:
    > System.out.println("x=10");
    > break;
    > case y:
    > System.out.println("y=10");
    > break;
    > default:
    > System.out.println("x!=10 and y!=10");
    > break;
    > }
    >
    > Hmmm, where would it go, to case x or case y?
    >
    > Rick
    >


    Why wouldn't it just go to the first case?
    Miguel De Anda, Jul 4, 2003
    #15
  16. Brian J. Sayatovic

    pete kirkham Guest

    rkm wrote:

    > Miguel De Anda wrote:
    >
    >> "rkm" <> wrote in message
    >> news:...
    >>
    >>>
    >>> doesn't it seem obvious that with your idea you could code
    >>> this indeterminant bit of code?
    >>>
    >>>
    >>> int x = 10, y = 10;
    >>> switch(x)
    >>> {
    >>> case x:
    >>> System.out.println("x=10");
    >>> break;
    >>> case y:
    >>> System.out.println("y=10");
    >>> break;
    >>> default:
    >>> System.out.println("x!=10 and y!=10");
    >>> break;
    >>> }
    >>>
    >>> Hmmm, where would it go, to case x or case y?
    >>>
    >>> Rick
    >>>

    >>
    >>
    >> Why wouldn't it just go to the first case?
    >>
    >>

    > It could go to case x, but can you imagine the maintenance headaches
    > you're going to have when some new person comes along and wants to add
    > another case to this?


    I the code was meant to, as the println statements suggest to be the same as

    switch(x) {
    case 10:
    System.out.println("x=10");
    break;

    then it wouldn't compile, as the next case would also be 10, as y is 10.

    On the other hand, if you intended the comparison to be made with the
    runtime value of x, you perhaps should give an example with meaningful
    results.

    In Java, the fall through implies an ordering to the case labels. This
    ordering would be such that the mapping of a non-constant case to a
    cascade of 'if's would be the same as that of a const case; ie:

    switch (X) {
    case A:
    default:
    a();
    break;
    case B:
    b();
    case C:
    c();
    }

    would be equivalent to

    switch_1:
    do {
    do {
    if (X==A) continue;
    switch_2:
    do {
    do {
    if (X==B) {
    b();
    continue;
    }

    if (X==C) {
    continue;
    }
    break switch_2;
    } while (false);
    } while (false);
    c();
    break switch_1;
    } while (false);
    a();
    } while (false);

    In terms of maintainance, the former wouldn't be any harder to maintain
    for A, B, C variable or constant, as the order is fixed. It also, at
    least to my eyes, is somewhat clearer.

    In the example you gave, 'X' is 'x' and 'A' is 'x' so the question of
    where to place the additonal statement is trivial- if you want it to
    have an effect, it has to be before the first one, because that is
    always true.

    > What's he/she going to do, hunt down all the
    > callers of the module to see who's passing in which values and
    > then try to predict where to place the new case label?


    Once such a construct has well defined semantics, the question is trival.

    > This poor person will
    > never know if the new code is going to execute unless the new case is
    > placed at the top to pre-empt all the other labels. How bug prone is
    > that?


    The bugs would be no worse that those in

    do {
    if (x==x) {
    System.out.println("x=10");
    break;
    }
    if (x==y) {
    System.out.println("y=10");
    break;
    }
    System.out.println("x!=10 and y!=10");
    break;
    } while (false);

    ie not in the syntax, but in the thinking that (x==x) -> x=10

    > Even in the simple hardcoded example above, if you think case x
    > should be the logical choice, then how do you ever get case y to
    > execute?


    in the example
    if (x==x) {
    foo();
    } else {
    bar();
    }

    how would you ever get bar to execute? Does this mean that if statements
    are inherently bug prone and a maintainance nightmare?


    > I don't think you can without something like a goto. I guess
    > you could say, well people shouldn't write code like that, but we all
    > know that if the compiler let's you, then someone will.


    In terms of 'what behaviour the compiler lets you do', we already have
    contructs of this power, which erm, just don't look as nice.


    Pete
    pete kirkham, Jul 4, 2003
    #16
  17. Brian J. Sayatovic

    rkm Guest

    pete kirkham wrote:
    > rkm wrote:
    >
    >> Miguel De Anda wrote:
    >>
    >>> "rkm" <> wrote in message
    >>> news:...
    >>>
    >>>>
    >>>> doesn't it seem obvious that with your idea you could code
    >>>> this indeterminant bit of code?
    >>>>
    >>>>
    >>>> int x = 10, y = 10;
    >>>> switch(x)
    >>>> {
    >>>> case x:
    >>>> System.out.println("x=10");
    >>>> break;
    >>>> case y:
    >>>> System.out.println("y=10");
    >>>> break;
    >>>> default:
    >>>> System.out.println("x!=10 and y!=10");
    >>>> break;
    >>>> }
    >>>>
    >>>> Hmmm, where would it go, to case x or case y?
    >>>>
    >>>> Rick
    >>>>
    >>>
    >>>
    >>> Why wouldn't it just go to the first case?
    >>>
    >>>

    >> It could go to case x, but can you imagine the maintenance headaches
    >> you're going to have when some new person comes along and wants to add
    >> another case to this?

    >
    >
    > I the code was meant to, as the println statements suggest to be the same as
    >
    > switch(x) {
    > case 10:
    > System.out.println("x=10");
    > break;
    >
    > then it wouldn't compile, as the next case would also be 10, as y is 10.


    In a more likely scenario those values would be passed in,
    as I suggested when I mentioned hunting down the callers to
    see what values they're passing in, and then the compiler
    can't help prevent this. But just to be clear, I'll remove
    the hardcoding, and since the labels are variables (as the
    OP was originally requesting), I'll pass those in too, and
    also I'll change each println so I don't get accused of
    printing non meaningful messages:

    public void dispatch( x, A, B )
    {
    switch( x )
    {
    case A:
    System.out.println("case A executed");
    break;
    case B:
    System.out.println("case B executed");
    break;
    default:
    System.out.println("neither case A or B executed");
    break;
    }
    }

    >
    > On the other hand, if you intended the comparison to be made with the
    > runtime value of x, you perhaps should give an example with meaningful
    > results.

    how is your example with calls to a(), b(), c() more
    meaningful than calls to println?

    >
    > In Java, the fall through implies an ordering to the case labels. This
    > ordering would be such that the mapping of a non-constant case to a
    > cascade of 'if's would be the same as that of a const case; ie:
    >

    why are you bringing fall-through into the discussion? I'm
    trying to make the point that indeterminant code can be
    written using the OPs request for labels with variable
    values. Adding fall-through to the discussion doesn't seem
    to clear up anything. Are you suggesting that fall-through
    somehow fixes whatever issues I have with the original
    request for variable-valued labels?

    > switch (X) {
    > case A:
    > default:
    > a();
    > break;
    > case B:
    > b();
    > case C:
    > c();
    > }

    To run with your example, what happens in this code when A
    and B, which I assume are variables, are equal? The
    compiler won't know, since they're run-time values, so it
    won't complain. So no-one can predict in the case where
    X==A and X==B whether a() will be called, or b() will be
    called, but clearly in this example, both cannot be called.
    Some believe case A should be executed because it comes
    first in the list, but I think that would lead to some
    obscure coding bugs when someone knows that X==B, yet b()
    never get's called (because for some reason A always equals
    B, so a() always gets called instead.)

    >
    > would be equivalent to
    >
    > switch_1:
    > do {
    > do {
    > if (X==A) continue;
    > switch_2:
    > do {
    > do {
    > if (X==B) {
    > b();
    > continue;
    > }
    >
    > if (X==C) {
    > continue;
    > }
    > break switch_2;
    > } while (false);
    > } while (false);
    > c();
    > break switch_1;
    > } while (false);
    > a();
    > } while (false);


    I couldn't make much out of that example, wrapping a
    do{}while(false) inside another do{}while(false), beats me
    what you're trying to illustrate with that. Maybe that
    anyone can write senselessly nested code?

    > > What's he/she going to do, hunt down all the
    > > callers of the module to see who's passing in which values and
    > > then try to predict where to place the new case label?

    >
    > Once such a construct has well defined semantics, the question is trival.

    That's the crux of it "well defined semantics". The labels
    with variable values don't have any well defined semantics.
    No matter how much you wish they did, they don't.

    >
    > > This poor person will
    > > never know if the new code is going to execute unless the new case is
    > > placed at the top to pre-empt all the other labels. How bug prone is
    > > that?

    >
    > The bugs would be no worse that those in
    >

    <snip>
    Just because someone can come up with thousands of bug prone
    examples of code, doesn't mean we should come up with new
    ways to write buggy code.

    >
    > > Even in the simple hardcoded example above, if you think case x
    > > should be the logical choice, then how do you ever get case y to
    > > execute?

    >
    > in the example
    > if (x==x) {
    > foo();
    > } else {
    > bar();
    > }
    >
    > how would you ever get bar to execute? Does this mean that if statements
    > are inherently bug prone and a maintainance nightmare?

    No, because the semantics are clear, because foo() gets
    called in all cases, and bar() never gets called. In the
    variable labels case, the semantics are not clear, and
    that's the trouble with it.

    > > I don't think you can without something like a goto. I guess
    > > you could say, well people shouldn't write code like that, but we all
    > > know that if the compiler let's you, then someone will.

    >
    > In terms of 'what behaviour the compiler lets you do', we already have
    > contructs of this power, which erm, just don't look as nice.

    You gave the perfect example with that do{}while(false)
    stuff above.
    Rick
    rkm, Jul 5, 2003
    #17
  18. Brian J. Sayatovic

    Tim Tyler Guest

    rkm <> wrote:
    : Miguel De Anda wrote:
    :> "rkm" <> wrote in message

    :>>doesn't it seem obvious that with your idea you could code
    :>>this indeterminant bit of code?
    :>>
    :>> int x = 10, y = 10;
    :>> switch(x)
    :>>{
    :>> case x:
    :>> System.out.println("x=10");
    :>> break;
    :>> case y:
    :>> System.out.println("y=10");
    :>> break;
    :>> default:
    :>> System.out.println("x!=10 and y!=10");
    :>> break;
    :>>}
    :>>
    :>>Hmmm, where would it go, to case x or case y?
    :>
    :> Why wouldn't it just go to the first case?
    :
    : It could go to case x, but can you imagine the maintenance
    : headaches you're going to have when some new person comes
    : along and wants to add another case to this? What's he/she
    : going to do, hunt down all the callers of the module to see
    : who's passing in which values and then try to predict where
    : to place the new case label? This poor person will never
    : know if the new code is going to execute unless the new case
    : is placed at the top to pre-empt all the other labels. How
    : bug prone is that? [...]

    It's no worse than:

    if (a) { b(); return; }
    if (c) { d(); return; }
    if (e) { f(); return; }

    ....which seems perfectly acceptable to me.

    Insisting they are runtime constants wouldn't be so bad.

    It is insisting that they are constant integers that is the
    biggest issue - IMO.

    I hear we will at least be able to switch on enumerations soon ;-)
    --
    __________
    |im |yler http://timtyler.org/
    Tim Tyler, Jul 6, 2003
    #18
  19. Brian J. Sayatovic

    Dale King Guest

    "dhek bhun kho" <> wrote in message
    news:p...
    > Hello John,
    >
    > "John C. Bollinger" <>, Wed, 02 Jul 2003 16:47:28
    >
    > 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.


    Enumerations are coming in JDK1.5. For ranges, feel free to vote for this
    feature request of mine:

    http://developer.java.sun.com/developer/bugParade/bugs/4269827.html

    --
    Dale King
    Dale King, Jul 7, 2003
    #19
  20. dhek bhun kho, Jul 9, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    548
    Mark P
    Apr 3, 2005
  2. Remco Poelstra
    Replies:
    5
    Views:
    904
    Peter Shaggy Haywood
    Jul 4, 2003
  3. pete
    Replies:
    2
    Views:
    1,453
  4. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,685
    Smokey Grindel
    Dec 2, 2006
  5. Skybuck Flying

    ints ints ints and ints

    Skybuck Flying, Jul 8, 2004, in forum: C Programming
    Replies:
    24
    Views:
    810
    Jack Klein
    Jul 10, 2004
Loading...

Share This Page