byte b; // ... int i = b & 0xff;
To get the effect of a 16-bit unsigned use char.
To get the effect of a 32-bit unsigned:
int i; // ... long l = i & 0xffffffffL;If you have an extensive amount of unsigned work to do, especially 64-bit unsigned, you might find the WBEM classes useful.
Here is haw to handle unsigned short:
// combining two unsigned shorts into an unsigned int. short ush = 4; short usl = 9999; int ucombined = ( ush & 0xffff ) << 16 | ( usl & 0xffff );
For 64-bit unsigned, consider that addition and subtraction give you the same results whether you consider the operands signed or unsigned. When you multiply two unsigned 64-bit operands together you get a 128-bit result which won’t fit in a long anyway, so 64-bit unsigned multiply is not useful. To implement an unsigned 64-bit division, you could handle it 32 bits as a time, much the way you handled decimal division in grade 4. Check the signs first, if they are 0 just use ordinary division.
You could store a signed or unsigned number in byte, char, int or long.
Sometimes you get the same result in terms of bits whether you treat quantities as signed or unsigned.
|Does Signed/Unsigned Matter?|
|< <= > >=||comparison|
|& | ~ !||bitwise|
|>>> >> <<||shift|
For large unsigned numbers, look into BigInteger and a BigDecimal.
Java’s Integer.toString interprets the value as unsigned. To display unsigned longs, use Long.toHexString. Writing a base 10 unsigned converter would be a challenge. You also might find com.mindprod.common17.ST.toLZHexString and com.mindprod.common17.ST.toHexString might be useful.
Working with a mixture of constants and bytes, it is easy to trip up when int constants don’t sign extend and (byte) constants do. Consider this example:
This page is posted
Optional Replicator mirror
|no blog for this page||Canadian
Your face IP:[22.214.171.124]
You are visitor number|