Java: byte literals and short literals

[John Goche]

Hello,

It appears to me that a way of specifying byte literals and short
literals has been left out of the Java language (unlike int literals
which need no special syntax and long literals which can be
specified by appending an L suffix to the number
being represented).

Anyone know how come these have been left out (I guess
it must be because I can always cast an int literal to a
short or byte).

Also, quite a bummer that there are no signed ints and longs.
When reading 16-bit unsigned values and 32-bit values from
the network I am being forced to use ints and longs thus
wasting a few bytes here and there, not that it matters
much I suppose.

Regards,

JG

 

[Torkel Franzen]

Anyone know how come these have been left out (I guess
it must be because I can always cast an int literal to a
short or byte).

All arithmetical expressions have type int, long, float, or double.
I suppose they didn't think it worthwhile to complicate matters any
further.

 

[Roedy Green]

Also, quite a bummer that there are no signed ints and longs.

you mean unsigned. For notes on kludging them see
http://mindprod.com/jgloss/unsigned.html

 

[Roedy Green]

Anyone know how come these have been left out (I guess
it must be because I can always cast an int literal to a
short or byte).

You don't need them. If you write

byte x = 3;

You don't need a cast.

If you write byte x = x + 3;

the addition will promote x and 3 to int anyway, so there is no point
in byte literals.

 

[Thomas Hawtin]

If you write byte x = x + 3;

the addition will promote x and 3 to int anyway, so there is no point
in byte literals.

As well as the missing cast, you are using x before it is defined there.

As an obscurity, you can write:

byte x = 3;
x += 1000;

Tom Hawtin

 

[Roedy Green]

As well as the missing cast, you are using x before it is defined there.

As an obscurity, you can write:

byte x = 3;
x += 1000;

byte x ....


x = (byte)( x + 100 );

needs a cast

but

x += 100;

does not

 

[Chris Uppal]

Anyone know how come these have been left out (I guess
it must be because I can always cast an int literal to a
short or byte).

Perhaps because an expression like
(byte)23
is, in effect, a byte-valued literal.

Also, quite a bummer that there are no signed ints and longs.

Bothers me too, sometimes. But that's how it goes...

-- chris

 

[Roedy Green]

Perhaps because an expression like
(byte)23
is, in effect, a byte-valued literal.

consider this SSCCE::

package com.mindprod.example;

/**
* Test unsigned byte calculation
*
* @author Roedy Green
*/
public class TestUnsignedByte
{
/**
* Test unsigned byte calculation
*
* @param args
* not used
*/
public static void main ( String[] args )
{
// 0xca is a negative number considered as a signed byte.
byte b = (byte)0xca;

// false, b sign extends, 0xca does not
System.out.println( b == 0xca );

// true, b sign extends, 0xca sign extends
System.out.println( b == (byte) 0xca );

// true, b chopped, 0xca does not sign extend
System.out.println( (b & 0xff) == 0xca );

// false, b chopped, 0xca sign extends.
System.out.println( (b & 0xff) == (byte) 0xca );
}
}





What prints? scroll down after you have decided what it should be:
For more detail see http://mindprod.com/jgloss/unsigned.html
It explains why you get he various answers you do.































false
true
true
false

 

[mert]

Hi

There are several reasons for your questions. Nevertheless, I want t
emphasize the most significant reason

The reason : Because, they are both limited primitive types. Yo
should be careful that they are limited with 8 and 16 bits which i
small enough for programmers. However, float and long primitiv
types are big enough for programmers. If a programmer always use lon
or float although he or she deal with small numbers or not larg
enough for them, it can allocate more memory size needlesly which ca
have potential to reduce the computer's performance

So, you should generally use int or double which can be beneficial fo
you I guess
Best wishes. :
http://www.devplug.com