Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

number ranges  RSS feed

 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
   final int c=2147483647+1; // this shows no error
int b=Integer.MAX_VALUE+1; // no error

  

final int a=2147483648; // shows an error that integer number id too large !

But why in the first 2 statements, this error is not shown ?  is a compile time constant variable an is assigned a compile time constant expression. So why doesn't the compiler at compile time detect that the value is too large as it did for variable a ? instead it chooses to wrap around ! why s this so ?

if I have something like this,

final short y=127+1;
byte z=y; // eror , as expected


final short y=90;
byte z=y; //
compiles fine, since y is a compile time constant variable and its value is known at compile time , which is within the byte range , so it compiles.

why this behaviour ?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37230
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In Java, math wraps. So if you try to add 1 to the max int value, it gives you the min int value. In your code, c and b are both -2147483648 if you print them out. So the code compiles even if it doesn't match your intent.
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what about the second example with variables y and z, involving byte and short types ?
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 37230
519
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dont' understand what you are asking with the second question. Can you elaborate?
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're confusing a short for a byte
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ooops, my error, I read it wrong.
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the answer you want is that when you increase the short from 127 to 128 you will lose information when saving it as a byte when wrapping.  I get the error of "incompatible types: possible lossy conversion from short to byte"
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'll take one more stab.  It is Friday and my brain isn't all there .

"Math wraps".  Therefore when you do the "math" with the adding of one it'll wrap.  But in the examples that don't compile, you are setting it with a direct number instead of doing "math that wraps".
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, after doing some experimenting, it appears that it is just an error with going from short to byte since when I replace 127+1 with 10 it still fails.  Maybe a trick question.
 
Mike Roundtree
Greenhorn
Posts: 17
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Disregard all my posts on this answer, here is the real answer

https://stackoverflow.com/questions/6889176/why-is-int-i-2147483647-1-ok-but-byte-b-127-1-is-not-compilable

Looks like the 127+1 isn't being converted to byte so you need to cast it first with (byte)
 
Roel De Nijs
Sheriff
Posts: 11338
177
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Roundtree wrote:Disregard all my posts on this answer, here is the real answer

Unfortunately that's not the real answer! Here is the one and only answer

First of all, adding 127 and 1 results in 128 (of type int) and 128 is within the short range so it can be assigned to variable y without the need of an explicit cast. Because y is a compile-time constant, the compiler is aware of the value of y and the compiler knows 128 is outside of the byte range and therefore gives you a compiler error when you try to assign it to byte variable z.

If the value of y would fit into the byte range (e.g. 100+1), the statement byte z=y; would compile successfully.

If the final keyword would be removed in the declaration of variable y, it's not a compile-time constant anymore. Thus the compiler does not know (nor care) about the value of y and will always give you a compiler error when trying to assign y to byte variable z without using an explicit cast.
 
blossom belle
Ranch Hand
Posts: 145
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thanks a lot roel ! was helpful !
thanks mike also
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!