• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

char z =1; no single quotes OK?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Taking Marcus Green's mock exam, I thought initializing char z = 1; would create an error because it had no single quotes. But it appears to compile. Why is this? Is it because char is considered an unsigned integer primitive, and the one (1) is being interpreted as unicode? passing strange... Thanks for any help.
------------------
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yep, you can get your unicode into a char anyway you see fit. In fact,
char c1 = '\u0041';
char c2 = 0x0041;
char c3 = 65;
char c4 = 0101; // octal
yield the same value for the c's when printed out ('A'). You just can't cast your char to anything of lesser or equal bitwidth.
Steve
sgwbutcher@aol.com
 
Ranch Hand
Posts: 1467
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Bill,
To add to what Steve said, this kind of assignment is a special kind. Special in the sense, assigning an integer literal to a primitive type var. The rule is the integer literal's value should be within the allowed value of of the assigned left hand side var type. Otherwise the compiler will complain.
So byte b = 1; //is OK
But byte b = 1000; // is NOT OK because the range of value a byte primitive can have is from -128 to +127 (i.e 2^7 to (2^7)-1
The same rule applies for all other primitives also.
regds
maha anna

[This message has been edited by maha anna (edited March 22, 2000).]
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When we try giving something like
float f = 4.4;
would give an error saying explicit cast needed to convert double to float. I guess this is a special case.
 
maha anna
Ranch Hand
Posts: 1467
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes. All integer literals default to primitive type 'int'.
All floating point literals default to type 'double'.
regds
maha anna
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
...and in M.A.'s previous post the special case she mentioned was for integer literals only (well, integral compile-time constants), not floating-points:
<code><pre>byte a = 127; // narrowing OK
char b = 65535; // narrowing OK
short c = 32767; // narrowing OK
int d = 2147483647; // OK
float e = 1.0; // narrowing not OK
float e = (float) 1.0; // narrowing OK
float e = 1.0F; // OK
double f = 1.0; // OK</pre></code>
 
Steve Butcher
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, this is one of the strangest things about Java--all integral literals are considered to be int (32 bits) and all floating point literals are considered to be double (64 bits) (1st "anomaly").
For integral types, you don't have to "cast down" the literal int into a smaller type such as byte, short, char so:
byte b = 2; // ok although 2 is an int
char c = 2; // ok although 2 is an int
short s = 2; // ok although 2 is an int
int i = 2; // ok
long l = 2; // this is okay although expected compiler to complain
long l2 = 2L; // this is the normal way
float f = 2.0; // BAD compiler barfs: "Explicit cast needed to convert double to float"
float f = 2.0f; // correct
double d = 2.0; // ok
If a cast is need to "narrow" for floating point variables why isn't it needed for integral types? (2nd "anomaly")
byte b1 = 2, b2 = 3, b3 = 3;
b3 = b1 + b2; // compiler barfs: "Incompatible type for =. Explicit cast needed to convert int to byte."
b3 = (byte)( b1 + b2 ); // this works
Where did the int come from? Arithmetic promotion--all operands to binary operators are promoted to int automatically if they are not int, float or double. So why use byte or short? (3rd "anomaly")
So...
1. The "yardstick" types are different bitwidths for integral types and floating point types (int & double) // not a big deal
2. Integral literal assignments do not follow casting/conversion rules but floating point literal assignments do.
3. Arithmetic promotion GUARANTEES that you have to cast back down to the smaller type if you use binary operands on anything smaller than an int even if they are all of the same type.
And this language was "designed" from scratch?
Steve
sgwbutcher@aol.com
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wow - beat you by less than 60 seconds.
 
Steve Butcher
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Actually, in reference to to Bill's original post, one important point has been neglected:
char c = 1; // is okay as we've all seen however...
System.out.println( "The char c is: " + c ); // does NOT print out "The char c is: 1"
Unicode \u0001 is the control character "soh". To get a '1' to print out you have to put 49 (\u0031) into c.
Steve
sgwbutcher@aol.com
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all ,
when i happen to print the same
i mean
char c = 1;
System.out.println( "The char c is: " + c );
the out put is the "char c is "
how come..?
plz clarify
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The 'toString()' method of a character will return the String representation of the character. So, if you initialize a character like:
char c = 57;
a '9' will be returned.
It is just another way to initialize characters by their number.
The number you try to get is not a normal character. All characters beneath 32 are special (antique) control characters.
Most of them don't return anything (usefull).
f.e. The BELL (7) character made a printer make a bell sound.
 
newtojava
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
got it frank .
thank's a lot.
regards
 
maha anna
Ranch Hand
Posts: 1467
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frank,
Just a small correction.
The 'toString()' method of a character will return the String representation of the character.
The 'toString()' method of Character class will return the String representation of the character it contains.
regds
maha anna

[This message has been edited by maha anna (edited March 25, 2000).]
reply
    Bookmark Topic Watch Topic
  • New Topic