Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / January 2006

Tip: Looking for answers? Try searching our database.

Java: byte literals and short literals

Thread view: 
John Goche - 15 Jan 2006 19:24 GMT
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 - 15 Jan 2006 19:55 GMT
> 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 - 15 Jan 2006 22:14 GMT
>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
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Roedy Green - 15 Jan 2006 22:16 GMT
>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.
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Thomas Hawtin - 15 Jan 2006 22:55 GMT
> 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
Signature

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

Roedy Green - 16 Jan 2006 00:09 GMT
On Sun, 15 Jan 2006 23:02:14 +0000, Thomas Hawtin
<usenet@tackline.plus.com> wrote, quoted or indirectly quoted someone
who said :

>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
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

Chris Uppal - 16 Jan 2006 11:17 GMT
> 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 - 16 Jan 2006 21:18 GMT
On Mon, 16 Jan 2006 11:17:51 -0000, "Chris Uppal"
<chris.uppal@metagnostic.REMOVE-THIS.org> wrote, quoted or indirectly
quoted someone who said :

>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
Signature

Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

mert - 17 Jan 2006 23:12 GMT
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


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.