|
Replies:
21
-
Last Post:
Sep 22, 2005 7:57 AM
by: nullpointer
|
|
|
|
|
|
|
Please add types uint, ulong etc...
Posted:
Jun 11, 2005 5:22 PM
|
|
|
Please add types uint, ulong etc... to the Java language.
Often I need to use long primitive type for 32-bit uint's.
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 12, 2005 8:04 AM
in response to: ulfzibis
|
|
|
I think it was one of the great decisions in Java not to have unsigned types. In my experience in C++ they always lead to type mismatch problems when mixing signed and unsigned types, and even bugs. For instance, a classic bug that arises with unsigned types is this:
for (uint n = max; n >= min; n--) {
...
}
This looks innocent enough, and works in almost every case, but if min is 0 the loop will never terminate. If n is signed, as in Java, it always works (except in the highly unlikely case that min is Integer.MIN_VALUE).
Another problem with unsigned types is deciding when a value should be unsigned: should Collection.size() have been defined to return an unsigned value? This seems logical, but this value will often be combined with signed values, and this will lead to problems, e.g.:
if (myCollection.size() < n)
This would produce a type mismatch warning (which means a potential bug) if n is signed. In Java, this is one less thing to agonize about.
IMHO unsigned values are rarely needed, and any support for them should not be 'in the language' but in a few simple library methods, e.g. a method for converting a byte (interpreted as an unsigned byte) to an int.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 16, 2005 11:52 AM
in response to: lucretius2
|
|
|
> for (uint n = max; n >= min; n--)
There are countless ways to write endless loops accidentally, often in ways that are hard to see.
int i, j;
// Loop on i
for( i = 0; i < 100; i++ ) {
//
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 16, 2005 9:58 PM
in response to: mypalmike
|
|
|
Can't you write yourself a set of lt/le/gt/ge (or lo/ls/hi/hs) methods and put up with it?
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 16, 2005 11:17 PM
in response to: tackline
|
|
|
of course not. EVERYTHING should be in the core language, and I mean EVERYTHING.
That way there's no more reason to ever write anything at all, all problems in the entire universe could be solved by a single method call.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 22, 2005 11:34 PM
in response to: jwenting
|
|
|
> EVERYTHING should be in the core language, and I mean EVERYTHING.
Sarcasm noted.
Name a common CPU arithmetic operation, besides unsigned integer comparison, that is not part of the core Java language. Even rotate, which is lacking in C, is built into the Java language. The implication that this is some baroque language feature request (like, say, regular expression parsing) is ridiculous.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 23, 2005 2:21 AM
in response to: mypalmike
|
|
|
regexp parsing indeed should also not be part of the core language, I fully agree with you there if that's what you mean!
If you're so eager for all kinds of stuff that Java doesn't do, either find a language that does offer that stuff or make your own.
Don't expect the world to change to fit you.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 23, 2005 12:13 AM
in response to: jwenting
|
|
|
Sorry, but language without basic numeric operation..
Question is - why we dont have unsigned types. Answer: Just because they was not implemented in OAK soon enough.. They were in plan.
http://www.artima.com/weblogs/viewpost.jsp?thread=7555
Unfortunately, the same end had things like assertions and pre/postconditions in definitions..
Btw. still used argument is - we need readable code. Do you realy think that idioms like (x & 0xff) help to reach it?
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 12, 2005 8:11 AM
in response to: ulfzibis
|
|
|
> Often I need to use long primitive type for 32-bit uint's.
May I ask you for what you need them?
Tom
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 13, 2005 10:17 AM
in response to: ulfzibis
|
|
|
I'm +0 on this.
On the one hand, it makes it much easier to port C++ applications to Java. As well, in some applications, memory could be saved. I often find myself looking for unsigned-byte (0-255) as opposed to upgrading to a signed-short.
On the other hand, it avoids type mismatches as described by a previous poster. Makes me wonder, though, why couldn't the compilers simply be smart enough to catch endless loops that do not terminate due to bad signed/unsigned casting? If one were to fix that, I would be +1 for adding unsigned types.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 13, 2005 1:27 PM
in response to: ulfzibis
|
|
|
I'm torn on this issue. I've needed unsigned variables twice before, both times when using a predefined protocol for communicating with a hardware device. This created a LOT of wasteful data conversion, since protocol ushorts became Java longs, and protocol ulongs (few, thank heaven) became BigInteger. In the end, I think I used bit-masking tools to handle these situations since I had to bit-mask so much other data anyway.
To my mind, these data types would become much more important if Java had more device communication support (USB, Firewire, etc.) It's usually not as much of an issue with network protocols, although it does pop up now and again.
The more I think about this, the more surprised I am that we still don't have these. I agree they're easy to misuse and abuse, but the compiler should be able to catch these instances, unless there's casting going on. Even then, casting should never be done carelessly, especially with 1.5's generic support.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 13, 2005 8:25 PM
in response to: ulfzibis
|
|
|
I feel your pain.
I too was interested to discover why they're not in there. The reason is because of the 'assembly language' of the JVM.
At some point the decision was made that the number of instructions has to fit into a single byte.
From sun's VM specification:
(http://java.sun.com/docs/books/vmspec/html/Overview.doc.html#7143)
"A Java Virtual Machine instruction consists of a one-byte opcode specifying the operation to be performed, followed by zero or more operands supplying arguments or data that are used by the operation. Many instructions have no operands and consist only of an opcode. "
and also:
"The decision to limit the Java Virtual Machine opcode to a byte and to forego data alignment within compiled code reflects a conscious bias in favor of compactness, possibly at the cost of some performance in naive implementations. A one-byte opcode precludes certain implementation techniques that could improve the performance of a Java Virtual Machine emulator, and it limits the size of the instruction set. "
and hence:
"Given the Java Virtual Machine's one-byte opcode size, encoding types into opcodes places pressure on the design of its instruction set. If each typed instruction supported all of the Java Virtual Machine's runtime data types, there would be more instructions than could be represented in a byte. Instead, the instruction set of the Java Virtual Machine provides a reduced level of type support for certain operations. In other words, the instruction set is intentionally not orthogonal. Separate instructions can be used to convert between unsupported and supported data types as necessary."
What that means is that Java will do certain kinds of casting for you, but not others.
Eg you can shove an int into a long and the compiler won't complain, because there is an opcode for that (The widening numeric conversion instructions are i2l, i2f, i2d, l2f, l2d, and f2d) and you can downsize certain things (The narrowing numeric conversion instructions are i2b, i2c, i2s, l2i, f2i, f2l, d2i, d2l, and d2f)
read i2d as int to double etc
The types byte, char etc are treated differently:
Note that widening numeric conversions do not exist from integral types byte, char, and short to type int. As noted in ยง3.11.1, values of type byte, char, and short are internally widened to type int, making these conversions implicit.
There's a big table of the number related opcodes in that section of the doco:
opcode byte short int long float double char reference
Tipush bipush sipush
Tconst iconst lconst fconst dconst aconst
Tload iload lload fload dload aload
Tstore istore lstore fstore dstore astore
Tinc iinc
Taload baload saload iaload laload faload daload caload aload
Tastore bastore sastore iastore lastore fastore dastore castore aastore
Tadd iadd ladd fadd dadd
Tsub isub lsub fsub dsub
Tmul imul lmul fmul dmul
Tdiv idiv ldiv fdiv ddiv
Trem irem lrem frem drem
Tneg ineg lneg fneg dneg
Tshl ishl lshl
Tshr ishr lshr
Tushr iushr lushr
Tand iand land
Tor ior lor
Txor ixor lxor
i2T i2b i2s i2l i2f i2d
l2T l2i l2f l2d
f2T f2i f2l f2d
d2T d2i d2l d2f
Tcmp lcmp
Tcmpl fcmpl dcmpl
Tcmpg fcmpg dcmpg
if_TcmpOP if_icmpOP if_acmpOP
Treturn ireturn lreturn freturn dreturn areturn
assuming that comes out correctly (eh, it probably wont) we see that there are 28 opcodes related to integers alone.
What that means is that if we were to add another 3 integery types, we'd have to add (roughly) another 90 opcodes to the instruction set... which is definitely going to blow out the 256 opcode limit.
Should Java be restricted to 256 opcodes? Perhaps not. I'm sure there's some interesting stuff that could be done if it was bigger. Is it too late to change now? Definitely. (My guess is that if they were going to increase it, the best time to do that would have been 1.5 when they put in templates... oops I mean 'generics' - since a lot of the 1.5 blargfulness produces source code that won't run on 1.4 anyway (whereas with earlier upgrades to the language it was relatively trivial to backport your code))
There's also some interesting stuff in there about byte alignment of data and so forth.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 15, 2005 1:51 PM
in response to: rickcarson
|
|
|
@ cowwoc, tomwitmer
Good examples !
Also imagine, if you are dealing with TIFF Tags. They are 16 bit values, see:
http://www.awaresystems.be/imaging/tiff/tifftags/private.html
@ rickcarson
Very good investigation from your side. But let me think a little bit (please give feedback, if I'm erroneous).
byte b1 = 1; internally: 0...000000001
byte b2 = -1; internally: 1...111111111
ubyte b3 = 255; internally: 0...011111111
byte b4 = 127; internally: 0...001111111
ubyte b5 = 127; internally: 0...001111111
...println(b2); --> -1
...println(b3); --> 255 // println knows that b3 is unsigned type
b2++; internally: 0...000000000
b3++; internally: 0...100000000
b4++; internally: 0...010000000
b5++; internally: 0...010000000
...println(b2); --> 0
...println(b3); --> 0 // println knows that b3 is unsigned type
...println(b4); --> -128 // println knows that b4 is signed type
...println(b5); --> 128 // println knows that b5 is unsigned type
int i1 = 1; internally: 0...0001
int i2 = -1; internally: 1...1111
uint i3 = 4294967295; internally: 1...1111
...println(i2); --> -1
...println(i3); --> 4294967295 // println knows that i3 is unsigned type
float f2 = (float)i2; opcode: i2f
float f3 = (float)i3; opcode: some more opcodes
...println(f2); --> -1.0
...println(f3); --> 4.294967295E9
i2++; internally: 0...0000
i3++; internally: 0...0000
...println(i2); --> 0
...println(i3); --> 0
b2 = Byte.parseByte("127"); internally: 0...001111111
b3 = UByte.parseUByte("255"); internally: 0...011111111
...println(b2); --> 127
...println(b3); --> 255 // println knows that b3 is unsigned type
b2 = Byte.parseByte("255"); --> NumberFormatException
b2 = UByte.parseUByte("255"); --> compile error
i2 = Int.parseInt("4294967295"); --> NumberFormatException
i3 = UInt.parseUInt("4294967295"); internally: 1...1111
Do you see any problems ?
Why we need more than 255 opcodes ?
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 20, 2005 4:44 AM
in response to: ulfzibis
|
|
|
IMHO, For the most part you can use the signed equivilents for unsigned values so long as you know the variable should be unsigned.
e.g.
Add three unsigned bytes together.
byte b1 = 2;
byte b2 = (byte) 200;
byte b3 = 20;
byte b4 = b1 + b2 + b3;
// prints 222
System.out.println(b4 & 0xFF);
For some operations you need to perform a conversion, but a signed value can store the same number of values as the unsigned equivilent.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 20, 2005 8:29 AM
in response to: peter_lawrey
|
|
|
You are right, I know this workaround.
But...
...println(b4 & 0xFF) in contrast to ...println(b4)
1. looks worse
2. needs more processing time (to calculate the & )
3. is errorprone, if have an API which returns a byte in sense of a ubyte. The user should allways remember to use it by b & 0xFF.
Also try:
int i = (int) 4294967294;
System.out.println(i & (int)0xFFFFFFFF); // (int) to avoid converting to 64 bit
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Jun 21, 2005 7:10 AM
in response to: ulfzibis
|
|
|
1. Masks such as & 0xFF are an idiom that a JIT could recognise to avoid actually generating additional instructions.
2. Having both signed and unsigned types is also error prone. How should types be promoted in expressions mixing these types? Lots of programmers seem not to know what C does in this case (arguably the wrong thing!).
3. If unsigned types were added, then would Java inherit the C/C++ rules for mixing these types or should it do something different. Neither alternative seems attractive.
4. I rarely feel the need for unsigned types when writing new code for Java. The problem comes with trying to reuse code from C.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 16, 2005 11:28 AM
in response to: mthornton
|
|
|
> The problem comes with trying to reuse code from C.
I have two reasons for wanting unsigned integers: counters and integrating with other systems. In my case, both come together to make Java a pain to work with. Where I work, we interface with various networking equipment and software. One thing we are often maniupulating is counters. These counters are, without exception, implemented as unsigned numbers (typically 32- or 64-bit). We have no control over this.
In Java, doing I/O on this data is a pain. String manipulation, byte array conversion, etc, makes for complex code.
In addition, manipulating the data is a pain. I can't simply compare two values, for instance. The quickest approximation of unsigned comparison is subtracting and comparing to zero, due to the fact that twos-complement subtraction is the same for signed and unsigned numbers. And this still fails to correctly handle the case of comparing two unsigned numbers that are > 2^30 apart. Handling that properly requires a fairly complex conditional to get the correct result. In any case, the end result is code that is less clear, suboptimal, and prone to unexpected edge-cases.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Sep 22, 2005 3:18 AM
in response to: ulfzibis
|
|
|
Your binary arithmetics are complete nonsense.
ubyte 255 is internally 11111111
byte -1 is the same 11111111
there is no ninth 'sign' byte, man.
for example with hypothetical nibble (4 bit) types
unsigned: signed
00 - 0000 00 - 0000
01 - 0001 01 - 0001
02 - 0010 02 - 0010
03 - 0011 03 - 0011
04 - 0100 04 - 0100
05 - 0101 05 - 0101
06 - 0110 06 - 0110
07 - 0111 07 - 0111
08 - 1000 -08 - 1000
09 - 1001 -07 - 1001
10 - 1010 -06 - 1010
11 - 1011 -05 - 1011
12 - 1100 -04 - 1100
13 - 1101 -03 - 1101
14 - 1110 -02 - 1110
15 - 1111 -01 - 1111
you get it? so, both byte and ubyte are 8 bits long,
ranges are 0...255 / -128...127.
have a nice day
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Aug 23, 2005 6:35 AM
in response to: ulfzibis
|
|
|
I'm glad, that this thread keeps alive.
I learned many new things about this subject.
For me, it seems that we have just become accustomed over long time to use workarounds like (x & 0xff).
Thanks to the community, for discussing this subject.
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Sep 22, 2005 3:46 AM
in response to: ulfzibis
|
|
|
Hi
I think problems appear during signed conversion of smaller types to larger like byte to int. E.g.
byte a = (byte) 0xFF
if ( a == 0xFF ) {
... do something
}
"do something" will never run because the expression "a" will be converted to int and in will have negative value. This type of errors appears in particulary when you work with byte[] arrays and IO streams.
I'd like that instead of defining unsigned types use modificator of unsighed conversion like:
if ( (unsigned) a == 0xFF ) ...
that will be used only in expressions.
Home task:
We have byte[4] array of IP address and we need convert it to write it to long variable.
Solution in Java:
...
Anton
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Sep 22, 2005 4:44 AM
in response to: nullpointer
|
|
|
wait a minute - you compare
0xFF
with
(byte)0xFF ( = -1 )
WHY should these two be the same?!
Same thing, different types: why should
(int)0.01123 ( = 0)
be the same as
0.01123
???
Would you really expect that, too?
|
|
|
|
|
|
|
|
|
Re: Please add types uint, ulong etc...
Posted:
Sep 22, 2005 7:57 AM
in response to: sbohmann
|
|
|
(byte) 0xFF = 11111111
and (-1) = 11111111 11111111 11111111 11111111
which is (int) ((byte) 0xFF). Cast to int is made by Java automaticly. And this casting provokes errors. Sometimes numbers are very practically to consider as unsigned.
|
|
|
|
|
java.net RSS
