Printable View
I need this explained to me in SIMPLE terms....
Why do I put the "L" in this statement:
long someNum = 2999999999L
Why can't I just use this:
long someNum = 2999999999
The book I have doesn't seem to explain the "why" it just says for me to do it. I want to know why!
Thanks for your help.
You should be able to omit it; if memory serves it is just an explicit cast to a long.
it is to signify that it is a long, otherwise the number will compile as an int. The same goes for floats, you must put an 'f' at the end, or it will be treated as a double.
:)
crptblade:
But the number won't fit into a int, so why would it compile as one? Is it a signed/unsigned (??) integer that it would be compiled as?
ints in Java are not from -32767 to 32767, it is something much larger (forgot at the moment).
The short datatype is equivlent to the integer datatype in Visual Basic it ranges from -32,768 to 32,767. *~ note ~ * This applies to Visual Basic 6 not VB.Net (aka VB7). int ranges from -2147483648 to 2147483647Quote:
ints in Java are not from -32767 to 32767, it is something much larger (forgot at the moment).
When im having trouble remembering the ranges of numeric primative types i often think of them in exponent form like this.
short = -2^15(-32,768) to 2^15(32,767)
integer = -2^31(-214783648) to 2^31(214783648)
I dont think that a number that large would compile to an integer.
Remember that a numerical overflow occurs when the result of a calculation is larger then the largest value that can be represented by it's type. So i think the same would apply when trying to initialize a variable with a value larger then it can hold.
I never said that it would. So im not sure where you got that from.Quote:
Trust me, the number I gave you will not fit into an int in Java (int's range from -2147483648 to 2147483647 and occupies 4 bytes). A long variable holds values from -9223372036854775808 to 9223372036854775807 and occupies 8 bytes. This is for Java, NOT VB.
Obviously this is for Java and not Visual Basic. I was just saying for comparison purposes.
Here is an example that i whipped up that might help. :p
Code:class castExamples{
public static void main(String[] args){
/*
if a integer value falls with in the range of the destination type
then no cast is required.
*/
byte b = 88; // int value in range. No cast required
byte b1 = (byte)128; // int value not in range. cast required
short s = 678; // int value in range. No cast required
char c = 33; // int value in range. No cast required
/*
Impilcit widening conversions
*/
long l = 2000; //Implicit wideing: int to long;
double d = l; //Implicit wideing: double to long
/*
narrowing conversions between char, byte (or short) always require
an explicit cast even if the source value is in range of the
destination type
*/
byte b2 = 33; // no cast required
short s1 = (short) 'a'; // value in range of short but explicit cast required
char c1 = (char) 'b'; // byte to char but explicit cast required
}
}
I'm sorry Dilenger4, but it seems that you are missing what I am saying. There MUST be a reason to have the L, otherwise it wouldn't be in the language. Someone put it there, and I want to know why. I know there are ways to get around it, that is not what I am asking. What I am asking is WHY is it is in the language and when would I need to use it.
You wouldn't. long l = 1000; would compile fine with or without the "L or l" becuse without the "L or l" an explicit wideing conversion would be performed. The only time you would need to append the "l or L" is if the integer literal was not in range of the integer type not the long type.Quote:
So, now if I am declaring the variable as long right off the bat, why do I need to append the L to the number to ensure it is a long, and not an int?
Right. I know what you are saying.Quote:
I can somewhat understand if the number I am assigning could fit into an int, then I would go ahead and cast it as a long to ensure the compiler understands what I want. But if the number is too big for an int anyway, why the cast?
This is kind of quirky to me also because even if the integer literal dosent fall within the integers range it's destination is a logn type so this should be permitted.Code:class X{
public static void main(String[] args){
long p = 30989l;
}
}
Code:class X{
public static void main(String[] args){
long l = 2147483647; // permitted
long z = 2147483648; // not permitted unless "L or l" is appended
}
}
Now you are catching on to what I am saying...
It seems as though even if you declare a variable of type long, it is an int as long as it holds what an int can hold. Though, the only way to really create a long, is to append an L to the end....I don't like that....lolQuote:
This is kind of quirky to me also because even if the integer literal dosent fall within the integers range it's destination is a logn type so this should be permitted.
code:--------------------------------------------------------------------------------
class X{
public static void main(String[] args){
long l = 2147483647; // permitted
long z = 2147483648; // not permitted unless "L or l" is appended
}
}
--------------------------------------------------------------------------------
Yeah your right. That's kind of $hitty. Other stuff is weird too. For instance, when assigining an integer that is within range of it's destination which is a smaller (or narrower) type no cast is needed. But when assigning say a char to a short that is within range a cast is needed. I sort of understand because i guess we are talking about maximum values 65535 (UniCode) vs 2147483647 (integer).
Code:/*
narrowing conversions between char, byte (or short) always require
an explicit cast even if the source value is in range of the
destination type
*/
byte b2 = 33; // no cast required
short s1 = (short) 'a'; // value in range of short but explicit cast required
I understand a cast up, because you need to tell the compiler to alocate more memory for the bigger variable, even though it isn't needed to put the number in, it is needed (by definition) to be the new variable type. Thats why the cast is needed.
hmm...that didn't sound very good, basically you have to append '0's to the number and 'fill' up the new variable.