Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32280 > unrolled thread

PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA")

Back to article view | Back to comp.lang.java.programmer

Contents

  PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") srcommunicationsvja@gmail.com - 2015-08-08 06:53 -0700
    Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-08 10:39 -0400
    Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eternal Hope <laughingspam99@gmail.com> - 2015-08-09 08:53 +0100
      Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") e.d.programmer@gmail.com - 2015-08-10 05:36 -0700
        Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-10 09:17 -0400
          Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") e.d.programmer@gmail.com - 2015-08-10 07:56 -0700
            Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-10 11:50 -0400
          Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Arne Vajhøj <arne@vajhoej.dk> - 2015-08-12 20:51 -0400
            Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-08-13 08:25 -0400
              Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") leif.roar@dimnakorr.com - 2015-08-13 08:43 -0500
        Re: PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA") Eternal Hope <laughingspam99@gmail.com> - 2015-08-10 15:39 +0100

#32280 — PLEASE SOLVE THIS ERROR (case 1:from=="VIJAYAWADA")

 switch(true){
        
               { case 1:from=="VIJAYAWADA"
                if(to=="HYDERABAD")
                    ticharge=3000;
                elseif(to=="MUMBAI")
                    ticharge=9000;
                elseif(to=="BANGLORE")
                    ticharge=10000;
                else
                    ticharge=20000;
                }
             {
                 case 2:from=="HYDERABAD"
                 if(to=="VIJAYAWADA")
                    ticharge=3000;
                 elseif(to=="MUMBAI")
                    ticharge=6000;
                 elseif(to=="BANGLORE")
                    ticharge=9000;
                 else
                    ticharge=19000;
                }
              {
                  case 3:from=="MUMBAI"
                  if(to=="VIJAYAWADA")
                    ticharge=9000;
                  elseif(to=="HYDERABAD")
                    ticharge=6000;
                  elseif(to=="BANGLORE")
                    ticharge=10000;
                  else
                    ticharge=17000;
                }
              {
                  case 4:from=="BANGLORE"
                  if(to=="VIJAYAWADA")
                    ticharge=10000;
                  elseif(to=="HYDERABAD")
                    ticharge=9000;
                  elseif(to=="MUMBAI")
                    ticharge=10000;
                  else
                    ticharge=21000;
                }
              {
                  case 5:from=="DELHI"
                  if(to=="VIJAYAWADA")
                    ticharge=20000;
                  elseif(to=="HYDERABAD")
                    ticharge=19000;
                  elseif(to=="MUMBAI")
                    ticharge=17000;
                  else
                    ticharge=21000;
                }

[toc] | [next] | [standalone]

#32284

On 8/8/2015 9:53 AM, srcommunicationsvja@gmail.com wrote:
>   switch(true){

     Point #1: This `switch' can never, never work, no matter what
comes before or after it.  (Well, if `/*' comes before it and `*/'
after it, the whole thing is a comment and "works" by doing nothing
at all -- but other than that, this `switch' is completely broken.)
Go back to your textbook, and re-read what `switch' is and does.

     Point #2: Please don't start three (and counting!) distinct
threads about the exact same problem -- and especially don't start
three (and counting!) threads in a fourteen-minute span!

     Point #3: When you're having a problem, don't just show your
failed attempt.  You ask for help with "this error," then you post
code that has many, many errors.  How are we to know which of them
you need help with?  Tell us more about your problem, tell us what
you want the code to do, and don't force us to guess.  Be explicit,
accurate, and complete: My crystal ball is in the shop.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32286

On 08/08/2015 14:53, srcommunicationsvja@gmail.com wrote:

>   switch(true){

true is a Java keyword representing the boolean value 'true'
you can't switch on a boolean value

>                 { case 1:from=="VIJAYAWADA"
>                  if(to=="HYDERABAD")
>                      ticharge=3000;
>                  elseif(to=="MUMBAI")
>                      ticharge=9000;
>                  elseif(to=="BANGLORE")
>                      ticharge=10000;
>                  else
>                      ticharge=20000;
>                  }

... what everyone else said



-- 
Laughing Spam Fritter

[toc] | [prev] | [next] | [standalone]

#32288

On Sunday, August 9, 2015 at 3:53:33 AM UTC-4, Eternal Hope wrote:
> true is a Java keyword representing the boolean value 'true'
> you can't switch on a boolean value

I think switch used to work on a boolean, then you could evaluate Strings in the case conditions by comparing your String to other Strings looking for the first case that evaluates to true.  In Eclipse now with JDK 8 compile settings this does throw an error.  The switch documentation states the switch value may now be a String starting with Java 7, int and enum also work.  Eclipse also flags an error if a case value is not a constant, making it seem difficult to do anything useful with a switch besides comparing a Switch, int, or enum to a set of values.

Since this sample is only comparing a String matrix this should be easy with a nested switch in Java 7+, though it also looks like schoolwork since a real program would be getting those values from a sort of database.

[toc] | [prev] | [next] | [standalone]

#32289

On 8/10/2015 8:36 AM, e.d.programmer@gmail.com wrote:
> On Sunday, August 9, 2015 at 3:53:33 AM UTC-4, Eternal Hope wrote:
>> true is a Java keyword representing the boolean value 'true'
>> you can't switch on a boolean value
>
> I think switch used to work on a boolean,

     Perhaps in some pre-1.0 proto-Java ("Oak"), but never in Java.
The earliest sources I can lay my hands on are a "Java 1.1 Certification
Study Guide" and "Java in a Nutshell (Second Edition)", both from 1997,
and both agree that switch only works on int values and on things
that promote to int.

     Besides, what advantage would switch on a boolean have, when
compared to an if or if/else?

> then you could evaluate Strings in the case conditions by comparing your String to other Strings looking for the first case that evaluates to true.

     That can't work (unless I've completely misunderstood what you're
saying).  The switch statement is not an if ladder.

> [...] The switch documentation states the switch value may now be a String starting with Java 7, int and enum also work.

     Section 14.11 of the JLS requires that the expression in switch
must be char, byte, short, int, Character, Byte, Short, Integer,
String, or an enum type.

> Eclipse also flags an error if a case value is not a constant,

     Evidence that Eclipse has read JLS section 14.11.

     By the way, is anyone else horrified at the bytecode generated for
a switch on a String value?  It produces what amounts to *two* switch
constructs *and* a set of if ladders (short ones with luck, but ...).
Roughly speaking,

	switch (theString) {
	case "Foo": fooStuff(); break;
	case "Bar": barStuff(); break;
	case "Baz": bazStuff(); break;
	}

turns into something like

	int _case = 0;
	switch (theString.hashCode()) {
	case 70822: if ("Foo".equals(theString)) _case = 1; break;
	case 66547: if ("Bar".equals(theString)) _case = 2; break;
	case 66555: if ("Baz".equals(theString)) _case = 3; break;
	}
	switch (_case) {
	case 1: fooStuff(); break;
	case 2: barStuff(); break;
	case 3: bazStuff(); break;
	}

String-switching is a convenience, sometimes, but it's a costly one.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32292

On Monday, August 10, 2015 at 9:18:08 AM UTC-4, Eric Sosman wrote:
>      Besides, what advantage would switch on a boolean have, when
> compared to an if or if/else?
> 
> > then you could evaluate Strings in the case conditions by comparing your String to other Strings looking for the first case that evaluates to true.
> 
>      That can't work (unless I've completely misunderstood what you're
> saying).  The switch statement is not an if ladder.
> 
> > [...] The switch documentation states the switch value may now be a String starting with Java 7, int and enum also work.
> 
>      Section 14.11 of the JLS requires that the expression in switch
> must be char, byte, short, int, Character, Byte, Short, Integer,
> String, or an enum type.
> 
> > Eclipse also flags an error if a case value is not a constant,
> 
>      Evidence that Eclipse has read JLS section 14.11.
> 
>      By the way, is anyone else horrified at the bytecode generated for
> a switch on a String value?  It produces what amounts to *two* switch
> constructs *and* a set of if ladders (short ones with luck, but ...).
> Roughly speaking,
> 
> 	switch (theString) {
> 	case "Foo": fooStuff(); break;
> 	case "Bar": barStuff(); break;
> 	case "Baz": bazStuff(); break;
> 	}
> 
> turns into something like
> 
> 	int _case = 0;
> 	switch (theString.hashCode()) {
> 	case 70822: if ("Foo".equals(theString)) _case = 1; break;
> 	case 66547: if ("Bar".equals(theString)) _case = 2; break;
> 	case 66555: if ("Baz".equals(theString)) _case = 3; break;
> 	}
> 	switch (_case) {
> 	case 1: fooStuff(); break;
> 	case 2: barStuff(); break;
> 	case 3: bazStuff(); break;
> 	}
> 
> String-switching is a convenience, sometimes, but it's a costly one.

String switch may be ugly behind the scenes but makes the most readable code where the value you're checking is already a String.  int switch may be easier but if you start with a String you have to convert it.
        switch (theString) { 
        case "Foo": fooStuff(); break; 
        case "Bar": barStuff(); break; 
        case "Baz": bazStuff(); break; 
        } 
This construct is easily readable and allows fall-through.  If you wanted to do the same thing and say that all Foo are also Bar you could take out the break.
        switch (theString) { 
        case "Foo": fooStuff();
        case "Bar": barStuff(); break; 
        case "Baz": bazStuff(); break; 
        } 
Alternatives?
1) Write an if statement (values must be mutually exclusive?):
  if (theString.equals("Foo")) {
     fooStuff();
  } else {
  if (theString.equals("Bar")) {
     barStufF();
  } else {
  if (theString.equals("Baz")) {
     bazStuff();
  }
2) Write an int switch based on the if statement?
  final int stringMatch;
  if (theString.equals("Foo")) {
     stringMatch = 1;
  } else {
  if (theString.equals("Bar")) {
     stringMatch = 2;
  } else {
     stringMatch = 3;
  }
        switch (stringMatch) { 
        case 1: fooStuff(); break; 
        case 2: barStuff(); break; 
        case 3: bazStuff(); break; 
        }
With a boolean switch, if a case allows a variable, you could do what the OP suggests:
  switch (true) {
  case theString.equals("Foo"): fooStuff(); break;
  case theString.equals("Bar"): barStuff(); break; 
  case theString.equals("Baz"): bazStuff(); break; 
  } 
With this construct you could test anything from String matching to object methods which return boolean.

[toc] | [prev] | [next] | [standalone]

#32293

On 8/10/2015 10:56 AM, e.d.programmer@gmail.com wrote:
> On Monday, August 10, 2015 at 9:18:08 AM UTC-4, Eric Sosman wrote:
>>
>> String-switching is a convenience, sometimes, but it's a costly one.
>
> String switch may be ugly behind the scenes but makes the most readable code where the value you're checking is already a String.
>  [...]

     As I said, "a convenience, sometimes."  FWIW, I've just taken a
quick scan through my own Java projects and have found exactly one
use of String-switch.

     For that matter, switch itself seems less useful in Java than in
other languages.  It's often -- not always, mind you -- preferable to
take advantage of polymorphism: Instead of enumerating all possible
behaviors at compile time as a switch construct must, encapsulate the
behavior in an interface and provide implementations thereof.  Then
you can "switch" on anything you want, as for example:

	Map<Thing,Behavior> behaviors = ...;
	...
	Behavior behavior = behaviors.get(anyThing);
	behavior.behave();

... and future code can easily add new, un-premeditated behaviors.
Aren't you glad Swing fires event notifications instead of hard-
wiring all possible responses in internal switch blocks?

     The switch statement has its uses, when you Really Really Know the
possible set of behaviors is firmly fixed for all time. Still, whenever
I write a switch statement I take it as a hint that my design might be
deficient, and that a better design might make the switch go away.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32316

On 8/10/2015 9:17 AM, Eric Sosman wrote:
>      By the way, is anyone else horrified at the bytecode generated for
> a switch on a String value?  It produces what amounts to *two* switch
> constructs *and* a set of if ladders (short ones with luck, but ...).
> Roughly speaking,
>
>      switch (theString) {
>      case "Foo": fooStuff(); break;
>      case "Bar": barStuff(); break;
>      case "Baz": bazStuff(); break;
>      }
>
> turns into something like
>
>      int _case = 0;
>      switch (theString.hashCode()) {
>      case 70822: if ("Foo".equals(theString)) _case = 1; break;
>      case 66547: if ("Bar".equals(theString)) _case = 2; break;
>      case 66555: if ("Baz".equals(theString)) _case = 3; break;
>      }
>      switch (_case) {
>      case 1: fooStuff(); break;
>      case 2: barStuff(); break;
>      case 3: bazStuff(); break;
>      }
>
> String-switching is a convenience, sometimes, but it's a costly one.

Is that code really so bad?

The hash code trick is probably improving performance by reducing
string comparisons.

The two switches are probably to avoid repeating code in
case of multiple labels for same action.

Makes sense to me.

It could be slow. It probably is slow in some cases. But I am
far from horrified.

Arne

[toc] | [prev] | [next] | [standalone]

#32319

On 8/12/2015 8:51 PM, Arne Vajhøj wrote:
> On 8/10/2015 9:17 AM, Eric Sosman wrote:
>>      By the way, is anyone else horrified at the bytecode generated for
>> a switch on a String value?  It produces what amounts to *two* switch
>> constructs *and* a set of if ladders (short ones with luck, but ...).
>> Roughly speaking,
>>
>>      switch (theString) {
>>      case "Foo": fooStuff(); break;
>>      case "Bar": barStuff(); break;
>>      case "Baz": bazStuff(); break;
>>      }
>>
>> turns into something like
>>
>>      int _case = 0;
>>      switch (theString.hashCode()) {
>>      case 70822: if ("Foo".equals(theString)) _case = 1; break;
>>      case 66547: if ("Bar".equals(theString)) _case = 2; break;
>>      case 66555: if ("Baz".equals(theString)) _case = 3; break;
>>      }
>>      switch (_case) {
>>      case 1: fooStuff(); break;
>>      case 2: barStuff(); break;
>>      case 3: bazStuff(); break;
>>      }
>>
>> String-switching is a convenience, sometimes, but it's a costly one.
>
> Is that code really so bad?
>
> The hash code trick is probably improving performance by reducing
> string comparisons.

     Possibly, but possibly not.  The hash computation inspects
every character of the string,[*] and the "yes, they're equal"
comparison inspects each character a second time.  Unless the
strings share long identical prefixes and differ only in their
suffixes, mismatches between unequal pairs will be detected after
only a few characters are inspected -- or even without inspecting
any characters at all, if the lengths differ.  That is, for strings
"chosen at random" (whatever *that* may mean), detecting inequality
a few times might well be cheaper than computing a hash.

     [*] Yes, I know that a String object caches its hash value the
first time it's computed and does not recompute it thereafter.  I'm
mostly thinking about getting a fresh String from some external source
and switching on it, which involves computing a new hash.  If you're
switching on the same String instance over and over again, the hash
cost amortizes toward zero and the trade-off trades off differently.

> The two switches are probably to avoid repeating code in
> case of multiple labels for same action.

     Also for fall-through from case to case, especially if the
case labels happen to include different strings with colliding
hash codes.

     Don't get me wrong: I've occasionally used string-switch myself
and agree it can be convenient.  But it seems to me that one cannot
say "The cost is worth while" if the cost is unknown.  (That's part
of what scuppered Boston's bid for the Olympics.)  Knowing the cost,
or at least having some notion of it, one may then choose to pay it;
that's all well and good.  But paying without knowing?  That's not
engineering, that's faith.

     And, hey: Isn't this the forum where folks get warned against
indiscriminate use of "+" to concatenate strings?  ;-)

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32320

Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
> 
>     Possibly, but possibly not.  The hash computation inspects
> every character of the string,[*] and the "yes, they're equal"
> comparison inspects each character a second time.  Unless the
> strings share long identical prefixes and differ only in their
> suffixes, mismatches between unequal pairs will be detected after
> only a few characters are inspected -- or even without inspecting
> any characters at all, if the lengths differ.  That is, for strings
> "chosen at random" (whatever *that* may mean), detecting inequality
> a few times might well be cheaper than computing a hash.

Don't forget that a) in practice you tend to switch on quite short 
strings and b) with the hash-code technique you'll almost never 
do more than _one_ string comparison regardless of the number of
case statements while with an if cascade you'd often have to do
several. 

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#32291

On 10/08/2015 13:36, e.d.programmer@gmail.com wrote:
> On Sunday, August 9, 2015 at 3:53:33 AM UTC-4, Eternal Hope wrote:
>> true is a Java keyword representing the boolean value 'true'
>> you can't switch on a boolean value
>
> I think switch used to work on a boolean,

I don't think so

anyway

boolean foo = true;

switch(foo){
	case true:
	...
	break;
	default:
	...
}

is about all you can do isn't it?
(meh! I *still* can't decide how to indent a case statement)

in which case [:-)] an if is more succinct

if(foo){
	...
}
else{
	...
}

... and is profoundly different to

switch(true)
case ???

where true is a reserved word and in no way an expression

Of course as always I await correction and suitable chastisment by the 
language lawers :-)


-- 
Laughing Spam Fritter

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web