short s1 =1;
short s2 =1 + s1;
this gives compiler err -Type mismatch: cannot convert from int to short
short is 16 bits , 1 doesn't violate this, the result will not violate it either.
int 32 bits would have 8 unnecessary bits ?
Please someone explain why i need to use int?
Performance on 32 bit machine?
Thank you
A bare number (i.e. that 1 in the "=1" as well as in "=1 + s1") is automatically interpreted as an int if you want it interpreted as a short do
"=(short)1" and "=(short)1 + s1".
Also the result of + is an int, not a short, regardless of the input types, unless one of them is a long, in which case it is a long, or a double, in which case it is a double.
thanks for replies
short s1 =(short)1;
short s2 =(short)1 + s1;
still give same error
do all arithmetic operators (+ - % / etc) always need int to perform operation?
thank you
short s2 =(short) (1 + s1);
To catch the "+" operation and cast the end result back to a short again.
Edit: And I take back reply number 1. The compiler is smart enough to cast the 1 to a short in the
short s1 = 1;
it seems (at least I don't get any errors or warnings) but it does not handle the + operation.
thanks for fast replies
why does java 'promote' smaller primitve type to int?
I guess same apply for byte, char.
thank you
the only thing I can guess is using 32bit machine more effectively
is this right?
I think it is to prevent overflows.
For an addition, one extra bit might be needed to hold the result.
For a multiplication, the twice the amount of bits might be needed
For example 0xffff fits in a short but 0xffff + (short)1 doesn't.
> why does java 'promote' smaller primitve type to int?
It doesn't. Numeric literals are defined always to be ints unless stated otherwise by a prefix. Just like "Hello" will always be a String and not a StringBuffer or anything else.
> guess same apply for byte, char.
The same what?
I think he meant: why is the result of adding two shorts with the + operator, an int, and not a short.
Oh, I see. Got that wrong then.
Anyway, it has nothing to do with 32 bit machines, since the Java language wouldn't be aware of that. The primitives only define value ranges, not memory sizes.
> Anyway, it has nothing to do with 32 bit machines,
> since the Java language wouldn't be aware of that.
I don't know; the VM is specified as a 32-bit VM, which would at least partially explain the preference toward 32-bit values as "standard" stack values.
[EDIT] I may have imagined reading that; I couldn't find the source after a quick search of the VM spec, and I also know there are recent 64-bit VMs, so I could be way off base.
~
> I don't know; the VM is specified as a 32-bit VM,
> which would at least partially explain the preference
> toward 32-bit values as "standard" stack values.
http://java.sun.com/docs/books/jvms/first_edition/html/Introduction.doc.html
The Java Virtual Machine knows nothing of the Java programming language, only of a particular file format, the class file format.
What part of the specification are you referring to? I mean, the 64 Bit JVMs are Java-"certified" as well, aren't they?
> The Java Virtual Machine knows nothing of the Java
> programming language, only of a particular file
> format, the class file format.
I don't think that contradicts what I said (the VM doesn't know of the language, but the Java language may well consider the VM), but please see my edit.
~
It would make sense to me to only define the mathematical operations for 32 bit values in an age of 32 bit machines
I imagine (I don't really know) that the underlying 32 bit machine (NOT just the o/s) would only define these operations for 32 bits... so in order for the machine to simulate 16 bit operations it would just fill the other 16 buts with 0's, which really doesn't gain anyone anything.
IMHO short's aren't really useful except in special cases like backwards compatibility, packed arrays, encryption, and other nefarious bit-twiddlings.
I just use int's by default, and long's and short's where they are required.
Keith.
> I may have imagined reading that; I couldn't find the source after a quick search of the VM spec...
Well, here may be some of where I inferred that from:
3.6.1 Local Variables
A value of type long or type double occupies two consecutive local variables. Such a value may only be addressed using the lesser index. For example, a value of type double stored in the local variable array at index n actually occupies the local variables with indices n and n +1; however, the local variable at index n +1 cannot be loaded from. It can be stored into. However, doing so invalidates the contents of local variable n.
~
As per JLS numeric values having no decimal parts are called integer literals. These values can be expressed in decimal, octal and hexadecimal forms. By default integer literals are in decimal form and are 32-bit values
here integer literal 1 is been added with a short type and during the + operation java does implicit casting (converting smaller datatypes into larger datatypes) on short and made it to an integer value. When you try to assign an integer type to a short you got the error.
> (the VM doesn't know of the language, but the Java language
> may well consider the VM),
I wouldn't contradict here. I just don't see how JVMs are supposed to exist for a multitude of systems, and then being specified to be 32 bit, rather than just being de facto not much else.
Does the JVM actually supply an abstraction of the machines fundamental mathematical operations?
> I just don't see how JVMs are supposed to exist for a multitude of systems, and
> then being specified to be 32 bit, rather than just being de facto not much else.
I agree. And I'm not well-versed enough to say; I've only written one rudimentary 16-bit VM (well, two - one with Java and one with C - haha) while trying to learn a little about assembly language. The JVM is far more complex than anything I've ever dived into, so I make no claims to have a deep understanding of it. I only noticed that the VM spec seems to all but require a 32-bit operand stack. :o)
~
Now we still haven't made a conclusion about why the result of adding two shorts is an int:
>short s1 =(short)1;
>short s2 =(short)1 + s1;
> still give same error
Is it to prevent overflows?
I think Java is not overflow-free, because it is always possible to do:s1 += (short)1;
> Now we still haven't made a conclusion about why the result of adding two shorts is an int:
It's that way because the language specification says that's what must happen.
http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.2
http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#170983
There really isn't any more conclusion to be made than that. As to why the language designers chose to make it that way, I'll defer to them. :o)
~
> > why does java 'promote' smaller primitve type to
> int?
>
> It doesn't. Numeric literals are defined
> always to be ints unless stated otherwise by a
> prefix.
Or the few exceptions like:
byte b = 1;
short s = 2;
> Just like "Hello" will always be a String and
> not a StringBuffer or anything else.
> > Anyway, it has nothing to do with 32 bit
> machines,
> > since the Java language wouldn't be aware of
> that.
>
> I don't know; the VM is specified as a 32-bit VM,
> which would at least partially explain the preference
> toward 32-bit values as "standard" stack values.
The JVM could support operations on smaller values, even with a 32-bit stack: it would just truncate the results when moving to a short or byte variable.
I think more a more likely reason is that there are only 256 possible bytecodes, of which 205 are already used: http://java.sun.com/docs/books/jvms/second_edition/html/Mnemonics.doc.html
There's just no room to add a full complement of mathematical, bitwise, and load/store operators for short and byte. And would they really add value? We're no longer in the world of 640kb main memories, so there's no reason to scrimp and save every byte (except, of course, for arrays)
> > > why does java 'promote' smaller primitve type to
> > int?
> >
> > It doesn't. Numeric literals are defined
> > always to be ints unless stated otherwise by a
> > prefix.
>
> Or the few exceptions like:
>
> byte b = 1;
> short s = 2;
There are no exceptions to the rule, that integer literals have type int unles stated overwise by suffix (not prefix, it probably was a typo).
In this example, "1" and "2" have type int, see JLS 3rd, 3.10.1: "An integer literal is of type long if it is suffixed with an ASCII letter L or l (ell); otherwise it is of type int (4.2.1)."
This example shows only assignment conversion (JLS 3rd, 5.2). In this case, it is the following clause
"In addition, if the expression is a constant expression (15.28) of type byte, short, char or int : A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable."
In this example constant expression ("1" or "2") is casted (narrowed) to byte or short. This is a same conversion, such as in following code, where constant of type int is casted to short.
public class Conversion {
private static final int VALUE = 1;
public static void main(String [] args) {
short x = VALUE;
System.out.println(x);
}
}
>> There are no exceptions to the rule, that integer
> literals have type int unles stated overwise by
<snip>
Got it; I was just too lazy (and I could not access it at the time) to look in the JLS to find the clause that explained the actual reason.
If we perform any arithmatic operation between two bytes,shorts,ints,chars-
i.e
short a=10;
byte b=20;
the resultant datatype of (a+b) is max(int,datatype of a,datatype of b)
So here the resultant datatype is int
ex-2
float a=10.5
int b=20;
resultant datatype of a+b is max(int,float,int)
so ans is float.
... and finally let us note that C, C++, PL/M, MPL, and most other languages I can think of behave the same way.
