byte data type

java-programmer, byte data type hello,
I am confused with byte data type. I want to know how following code
gives result as -12?
byte b = (byte) 0xf4;
System.out.println("b=" +(byte)b);

regards,
rahul

java-programmer >> byte data type <email***@***.com> schreef in bericht
news:email***@***.com...
> hello,
> I am confused with byte data type. I want to know how following code
> gives result as -12?
> byte b = (byte) 0xf4;
> System.out.println("b=" +(byte)b);

The byte type is a signed type. (byte)-12 is equal to (byte)0xf4. (int)0xf4
is too big for byte, so it appears equal to (int)0xfffffff4.

java-programmer >> byte data type On 14 Aug 2005 03:11:18 -0700, email***@***.com wrote or quoted :

>I am confused with byte data type. I want to know how following code
>gives result as -12?
>byte b = (byte) 0xf4;
>System.out.println("b=" +(byte)b);

byte is signed. It was an idiotic holdover from the days of C where
chars were 7 bits.

See http://mindprod.com/jgloss/unsigned.html for how to fake unsigned
bytes.

java-programmer >> byte data type Roedy Green wrote:
>
> byte is signed. It was an idiotic holdover from the days of C where
> chars were 7 bits.

C does not specify the number of bits to a char. Nor if it is signed or
unsigned (usually they are unsigned). It doesn't even specify if signed
chars use two-complement notation.

I don't really think it is the business of a high level language, such
as Java, to have comprehensive support for bit bashing.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> byte data type On Sun, 14 Aug 2005 20:29:05 +0100, Thomas Hawtin
<email***@***.com> wrote or quoted :

>C does not specify the number of bits to a char. Nor if it is signed or
>unsigned (usually they are unsigned). It doesn't even specify if signed
>chars use two-complement notation.

Yes they had chaos. When people used only 7-bit ASCII it did not
matter, and the signed was a nice feature to use for short offsets.

Back then you had compiler options to consider byte as signed or
unsigned, but tradition left it signed.

Java went with the signed tradition even though nowadays 99% of the
time you want unsigned. Perhaps sun hardware is signed byte only.

I know Intel circa 386 used be unusually slow at handling signed
bytes.

java-programmer >> byte data type Roedy Green wrote:
> On Sun, 14 Aug 2005 20:29:05 +0100, Thomas Hawtin
> <email***@***.com> wrote or quoted :
>
>
>>C does not specify the number of bits to a char. Nor if it is signed or
>>unsigned (usually they are unsigned). It doesn't even specify if signed
>>chars use two-complement notation.
>
>
> Yes they had chaos. When people used only 7-bit ASCII it did not
> matter, and the signed was a nice feature to use for short offsets.
>
> Back then you had compiler options to consider byte as signed or
> unsigned, but tradition left it signed.

I'm pretty sure most compilers went with unsigned (although I may of
course be mistaken). unsigned chars mean you can sensible have EOF as -1.

> Java went with the signed tradition even though nowadays 99% of the
> time you want unsigned. Perhaps sun hardware is signed byte only.

99% of the time you just don't care. It's important if you are doing
byte twiddling to read some format. But then you do it for a few of your
simple datatypes and you're done. The only large use is for constants
used in the formats.

Java has bytes because it has byte arrays. Same with shorts. IMO, it'd
be confusing for some numerical types to be signed and others unsigned.
chars as a numerical type was a mistake.

> I know Intel circa 386 used be unusually slow at handling signed
> bytes.

Surprises me. IIRC, ARMs before the ARM7T (1994) did not have signed
byte loads. As you are on the whole unlikely to do anything that makes
distinguishes between signed and unsigned on 8-bit data, the 1.5
instruction overhead is not a big deal.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/

java-programmer >> byte data type Roedy Green wrote:
> Java went with the signed tradition even though nowadays 99% of the
> time you want unsigned. Perhaps sun hardware is signed byte only.

I suspect most of the time it makes absolutely no difference whether it
is signed or unsigned. For the main operations on bytes (the bitwise
ones) signedness makes no difference except for right shift (but that's
why there's >> and >>>).

Just curious. What other operations are you doing on bytes where the
signedness matters? I would consider printing out bytes in decimal
or doing division on them to be uncommon, but maybe I am wrong.

java-programmer >> byte data type On Sun, 14 Aug 2005 22:30:32 +0100, Thomas Hawtin
<email***@***.com> wrote or quoted :

>I'm pretty sure most compilers went with unsigned (although I may of
>course be mistaken). unsigned chars mean you can sensible have EOF as -1.

IIRC C defaulted to signed and C++ defaulted to unsigned for Borland.

All I will say for sure is that it was not defined by the language,
but by a compiler switch.

java-programmer >> byte data type On 14 Aug 2005 16:14:23 -0700, email***@***.com wrote or quoted :

>Just curious. What other operations are you doing on bytes where the
>signedness matters?

If you use bytes to index translate tables.

If you are fiddling around flipping endianness.

if you are displaying with decimal or hex.

if you are doing base64 encoding.

if you are doing encryption.

if you are using bytes to compactly store small ints.

if you are playing with RGB

java-programmer >> byte data type Roedy Green wrote:
> On 14 Aug 2005 16:14:23 -0700, email***@***.com wrote or quoted :
>
> >Just curious. What other operations are you doing on bytes where the
> >signedness matters?
>
> If you are fiddling around flipping endianness.
>
> if you are doing base64 encoding.
>
> if you are doing encryption.
>
> if you are playing with RGB

That's a good list of byte applications, but I was really searching
for operations, not applications. It makes no difference if you
just use bitwise operations (using >>> instead of >>), plus,
minus, times, equality. I think the list above falls in this category.
For example, endianness flipping only seems to involve
bit-whacking operations.

> if you are displaying with decimal or hex.
>
> if you are using bytes to compactly store small ints.

OK, if you need to display bytes in decimal or do division/
remainder on small integers, I agree. But how often does
that arise.

> If you use bytes to index translate tables.

Yes, I think using bytes as array indices is a compelling
example, e.g., for any kind of lookup table on bytes.
I can also see how this operation arise in some
of the other applications too.

As I said, I was really looking for operations, not
applications. The array indexing one was exactly the sort
of answer I was searching for. Thanks Roedy!

java-programmer >> byte data type On 2005-08-14, Thomas Hawtin penned:
>
> I don't really think it is the business of a high level language,
> such as Java, to have comprehensive support for bit bashing.

When I was assigned the job of parsing and displaying binary data
generated by a native app in Java, I was really happy that it supported
bit bashing.

--
monique

Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

java-programmer >> byte data type On 15 Aug 2005 04:06:45 -0700, email***@***.com wrote or quoted :

>That's a good list of byte applications, but I was really searching
>for operations, not applications. It makes no difference if you
>just use bitwise operations (using >>> instead of >>), plus,
>minus, times, equality. I think the list above falls in this category.
>For example, endianness flipping only seems to involve
>bit-whacking operations.

I could give you some code, e.g.
http://mindprod.com/products1.html#LEDATASTREAM,
http://mindprod.com/products1.html#WRAPPER and you can see how much of
it still works when you yank out all the & 0xff operations.

I can't think of a time I wanted signed bytes in the last 8 years.

java-programmer >> byte data type
Roedy Green wrote:
> On 15 Aug 2005 04:06:45 -0700, email***@***.com wrote or quoted :
>
> >That's a good list of byte applications, but I was really searching
> >for operations, not applications. It makes no difference if you
> >just use bitwise operations (using >>> instead of >>), plus,
> >minus, times, equality. I think the list above falls in this category.
> >For example, endianness flipping only seems to involve
> >bit-whacking operations.
>
> I could give you some code, e.g.
> http://mindprod.com/products1.html#LEDATASTREAM,
> http://mindprod.com/products1.html#WRAPPER and you can see how much of
> it still works when you yank out all the & 0xff operations.

Now I see the problematic operation -- it's not any of the bitwise or
arithmetic operations on bytes, but rather the (implicit) cast from a
byte
to an integer.

(byte1 & 0xff ) << 16

> I can't think of a time I wanted signed bytes in the last 8 years.

You've convince me!

One more (related) complaint about bytes - why are bytes (and shorts)
treated like second class primitive types, e.g., they're promoted to
ints so expressions like byte1 = byte2 | byte3 won't compile (although
byte1 |= byte2 is legal)? This only seems to exacerbate the amount of
casting when using (signed) bytes.

java-programmer >> byte data type On 16 Aug 2005 06:28:44 -0700, email***@***.com wrote or quoted :

>
>One more (related) complaint about bytes - why are bytes (and shorts)
>treated like second class primitive types, e.g., they're promoted to
>ints so expressions like byte1 = byte2 | byte3 won't compile (although
>byte1 |= byte2 is legal)?

It is because of the JVM. The stack elts are 32 bits wide and most of
th JVM operators that work on the top two stack elts are thus int
operators.

Rememember than Java orginally was designed for TV set top boxes where
you had limited RAM and hence a limited op code set in your JVM.

java-programmer >> byte data type Roedy Green wrote:
> On 16 Aug 2005 06:28:44 -0700, email***@***.com wrote or quoted :
>
>
>>One more (related) complaint about bytes - why are bytes (and shorts)
>>treated like second class primitive types, e.g., they're promoted to
>>ints so expressions like byte1 = byte2 | byte3 won't compile (although
>>byte1 |= byte2 is legal)?
>
>
> It is because of the JVM. The stack elts are 32 bits wide and most of
> th JVM operators that work on the top two stack elts are thus int
> operators.
>
> Rememember than Java orginally was designed for TV set top boxes where
> you had limited RAM and hence a limited op code set in your JVM.

There's no reason for a one-to-one mapping from operators to byte codes
(as seen from the |= on bytes). The problem is that if you add to bytes
or shorts together and assign to an int, you should be surprised by
overflows. It's very easy to have an overflow in the middle of an
expression, even if the end result would always be in range were all
operators to work with arbitrary precision.

Like Java byte code, it's normal for modern processor instruction set
architectures not to support eight and sixteen bit arithmetic and logic.

In terms of Java source, it was probably a mistake to allow compound
operator assignments narrow casting.

Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/