I am having problems though. It seems the compiler does not do implicit casting for 64 bit values.
Here are some examples (in all cases the input is a System.Int64 value):
f1(1
); // This does not work because it think's 1 is an int and therefore thinks I'm trying to reference a wrong function.f1((UInt64) 1); // This works fine
f1((UInt64) 0x1122334455667788); // This does not work.
The problem with the last case is that it says it's a wrong value for int litterals.
While the first case is annoying it's something I can live with. The 2nd case is breaking my compile though.
Any advice how to get 64 bit int's working
Thanks in advance.
-- Henrik
64 bit integer support
bamacoder
The main reason should be that Java specs does not suport Unsigned Integer types. C# does support them and hence support implicit conversion.
In J# though, we can use them using .NET System.UInt structures but you would have to use them explicitly,
-Prem
cskelton
The first case f1(1) is not possible because you are doing upcasting, which needs to be explicit.
In the the third case, f1((UInt64) 0x1122334455667788); this hexadecimal number needs to have a 'l' suffix else it will be always treated as a signed int and compiler will complain that signed int cant contain this big value.
It needs to be noted that in the absence of any suffix after the number, integer is always treated as signed int, and floating point is always treated as double.
Thanks,
Prem
Kenny99
What is to motivation for always treating numbers as signed ints In C# I don't think there is such a limitation
I'm especially puzzled over the 1st. case with f1(1). I think implicit casting would be more natural in the same way it happens in other languages. I mean it's just a number which fits in the range of UInt64 and has no minus sign.
-- Henrik