Operators Question

[Ashwin Kumar]

In K&B book..

It says.. byte b = 27; >> is legal because the compiler automatically narrows the literal value to byte and It casts automatically.
like byte b = (byte)27;
Ok, but when we say

byte a = 3;
byte b = 9;
byte c = a + b;

>>> since the resulting value is 12 the compiler gives error:
possible loss of precision.

It would have compiled if we say

byte c = (byte)(a + b);

My question is why didn't the compiler automatically casts here ??, why do we need to explicitely cast here ?, please explain..

[rajaraman navaneethan]

hi friend,
refer K&B book pg:148 first 3 lines of the last paragraph.
the result of an expression involving anything int sized or smaller is always an int.
consider the following example and compare it with that u have provided.
byte a=100;
byte b=50;
byte c=a+b;
now the answer is 150 which is clearly out of range for a byte,but well with in the range of an integer.so we need an explicit cast in this case.
regards
raja

[Ashwin Kumar]

Hi Raja,

The example which i took is from K&B book only, my question is it says when we say >> byte b = 27; compiler automatically casts it , right ?, why didnt we cast here explicitely ??, 27(literal integer) won't fit in to byte , right??

[Alex Belisle Turcot]

Hi,

When you are doing calculation (like a+b or a-b or a*b...), by default it is converted to at least int. For equal/larger type (long-64bit, float-32bit, double-64bit) it is converted as needed.

So, because a+b is automatically converted to int, you need to cast to byte.
Note that if you do c+=b, it works fine.

Alex
[ April 27, 2005: Message edited by: Alex Turcot ]

[Amit Das]

hi shonak,

well i think ppl yet answered haven't underestood ur questn.....right???
well if i've understood it correctly then the simple answer is :
byte b = 27 //1 legal
byte b = 127 //2 legal
byte b = 128//3 illegal
byte b = 27d //4 illegal
byte b = 27f //5 illegal

now life is easy
max value of a byte primitive can be 127.
all of them above are compile-time constants, so the compiler is clever enough to to allocate only 128 bits for the variable in the memory(stack or heap) it dosen't asks us to do a explicit cast, required otherwise.
you can see at line 3,4,5 since the compiler can see that even if allocates 128 bits, its not suffice.

in ur case:
byte c = a + b;//not legal where a and b are byte primitives
byte c = (byte)(a + b); //explicit cast req.
since a and b are not compile-time constants we have to do an explicit cast

well again if u declare a and b as final(actually as constants), then again
u'll see u dont require an explicit cast. As in:

final byte a = 7;
final bute b = 8;

byte c = a + b; //no need to do explicit cast as 'a' and 'b' are now compile-time constants

Reality is something more than meets the eye ;-)

well in case of any doubts feel free to get back

amit

[Ashwin Kumar]

HI Amit, Well I think I did declared a and b as compile time constants but I think when I do (a + b) the result is int, because of this I need to explicitly cast it to byte.
By the way I didn't understand why this will work with out casting if I declare them as final??

[Ashwin Kumar]

Amit, I think I overlooked your answer I got it now..thanks..

[Alex Belisle Turcot]

Hi Amit,

thx for tips with primitives declared as final, I did not know that.

However, I just tested it, if the final variables are not assigned any value at declaration, they are not compile time constant and you have to cast them.

Alex
[ April 27, 2005: Message edited by: Alex Turcot ]

[Amit Das]

Alex,

plz use jdk1.4.2_04 ....any 1.4 version, amy be u r using lower one.
this code works without cast in my m/c

class Alex {
final byte b = 9;
final byte c = 8 ;
 
public static void main(String[] args) {
new Alex().call();
}
 
void call() {
byte a = b + c;
System.out.println(a);
}
}
  

any doubts.....dont hesitate

[Amit Das]

aahhh....i got ur point .....i think i've misunderstood ur point.
I've to say u r right.

Thanx for notifying me.......as i'm yet to appear fot the day

amit