• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

RouhdUp Game  RSS feed

 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a quesiton in the RoundUp Game that pertains to a
byte that is incremented by a unary operator.
ie.
byte b;
b++;
according to the sybex java two study guide pg 107.
primitative data type of byte short and char are converted to an
int before a ++ or -- operator is applied.
Your Roundup question says that a byte will not be converted.
Who is correct?
 
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Yup, I have RHE, and page 107 says what you say.
I suppose you know the famous example with:
byte a=1;
byte b=2;
byte c;
c=a+b;
which give compiler error.
Now, please try this one:
byte a=1;
byte b=2;
a+=b;
This is all I am saying so far. I recall that I saw somewhere, Marcus tutorial or Brogden, that for ++, --, +, -, +=, aritmetic promotion is not happening. Maybe someone else will give light.
Bye for now.
 
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
faced the same problem, looked up the JLS.. ( see 5.2- assignment conversions )
It says:
"Assignment conversion occurs when the value of an expression is assigned to a variable: the type of the expression
must be converted to the type of the variable. ...a narrowing primitive conversion may be used if all of the following conditions are satisfied:
1. The expression is a constant expression of type int.
2. The type of the variable is byte, short, or char.
3. The value of the expression (which is known at compile time, because it is a constant expression) is representable in the type of the variable.
If the type of the expression cannot be converted to the type of the variable by a conversion permitted in an assignment context,
then a compile-time error occurs. "
in the code,
byte a=62;
byte b=63;
byte c;
c=a+b;
the point 3 is not being satisfied as the expression on the right hand side, (a+b) is NOT a constant expression. the result of the addition of two byte variables may exceed the maximum size allowed by a byte, and compiler doesnt know if thats going to happen or not. ( example, if that was 65 and 63 )So it forces a cast expression.
on the other hand, if we write,
byte c;
c = 62+63;
that is a constant expression, which the compiler evaluates, and knows that the value fits into a byte ( <127 ).. and so there is no problem.
It might also be noted that a number, such as 63, is actually an integer literal. ( i couldnt find a way of specifying a byte literal)
Now, the question arises, why is it allowed to have
a+= b; //no compile error, values might be trimmed at run time
but not,
a = a+b //compile error
I guess thats answered in JLS again, ( sec 15, assignment operators )
basically, there is an implicit cast applied in the compound assignment expression.
JLS says:
"A compound assignment expression of the form E1 op= E2 is equivalent to E1 = (T)((E1) op (E2)), where T is the type of
E1, except that E1 is evaluated only once."
following code shows the cases:
----
public class asstest
{
public static void main( String [] args)
{
byte a=65;
byte b=63;
byte c,d;
//this is ok .. since we know the value at compile time
c = 62+63 ;
//this isnt, a+b may exceed 127 .. so need a cast
//d = a+b;
//this is ok, since implicitly converted to a = (byte)( a + b)
a += b ;
//this isnt , again the same reason.
// a = a+b;
System.out.println( a +":" +c );
}
}
-----

Hope that helps. gurus correct me.
cheers,
vivek
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sound interesteing... thanks for the info.
BUT
The question was:
There is a quesiton in the RoundUp Game that pertains to a
byte that is incremented by a unary operator.
ie.
byte b;
b++;
...
according to the sybex java two study guide pg 107.
primitative data type of byte short and char are converted to
an int before a ++ or -- operator is applied.
...
according to the RoundUp question in question.
says that a byte will not be converted before a ++
or -- unary operator is applied.
...
Which is the correct answer?
Should the RoundUp question or answer be changed?
Who is correct?
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lets go to JLS again. Section 15.13.2 says


Before the addition, binary numeric promotion (�5.6.2) is performed on the value 1 and the value of the variable. If necessary, the sum is narrowed by a narrowing primitive conversion (�5.1.3) to the type of the variable before it is stored.


The following example proves this point.
<PRE>
class ByteTest
{
public static void main( String[] s)
{
byte b = 127 ;
byte c = ++b ;
}
}
</PRE>
Looks like this rules apply only for the unary increment and decrement operators. Believe me, this is new for me!!
Hope this helps,
Ajith
 
Rancher
Posts: 241
Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
two additional points on this that I found while cramming:
while it's true that
byte a=1; byte b=2; byte c=a+b;
won't compile, this will:
final byte a=1; final byte b=2; byte c=a+b;
since the final bytes are treated as compile-time constants.
also:
byte a=1; byte 2= ++a;
will compile, but this won't:
byte a=1; byte 2= +a;
That one's kind of a noodle bender for me. I guess it's that the incremental operator is considered some sort of constant-related operation, since you are always changing it by exactly one; but the unary sign (if it was negative) could flip a number from + to -, changing it by a non-constant amount, so it won't take, even if it is the unary + operator. Perhaps someone has deeper knowledge on that.
Eric B.
 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Can somebody summarize on arithmetic operations regarding conversions, widening and casting???
I'm sorry to ask this way, but this is really confusing.
Thanks a lot for your help.
Sushma
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me try..
Numeric literals are checked at compile time for overflow
and assignment conversions. Widenings rules checked, overflow rules are
not checked.
<PRE>
byte a = 178 ; // Incompatibility checked.

byte b = 127 ;
++b ; // Overflow not checked
</PRE>
Shorthand assignment operators( +=, -=, *= etc ) do not need explicit
casting. The result is automatically narrowed down to the type being
assigned to, possibly losing precision.
<PRE>
byte a = 10 ;
byte b = 20 ;
b += a ; // Compiler is
</PRE>
Final variables are resolved at compile time and hence behaves the
same way as constants.
<PRE>
final byte a = 10 ;
final byte b = 20 ;
byte c = a + b ; // No Error
</PRE>
For ++ and -- operators, compiler promotes the numbers to int, and
after the operation, narrows the result to fit into the operand type.
<PRE>
byte a = 127 ; ++a ; // No Error
</PRE>
In all other situations, a result of an arithmetic operation is
atleast as wide as an int and atmost as the widest of the operands.
Explicit casting required wherever narrowing conversion is required.
The famous examples,
<PRE>
byte a = 1 ;
byte b = 2 ;
byte c = a + b ; // Error!

int i = 1 ;
byte j = i ; // Error

final int k = 1 ;
byte m = k ; // No Error
</PRE>
I am sure this covers most of it, though it may not be complete.
Feel free to comment/balk/scream/thrash me if I am wrong!!
Ajith
[This message has been edited by Ajith Kallambella (edited May 24, 2000).]
 
Sushma
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ajith,
thanks a lot for the reply. It was very helpful.
So, it means that for final variables, the values are not promoted to int before they are assigned to their rspective types..right???
I want to confirm this with u.
Thanks again for the help...
Sushma
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sushma,
Actually the operands undergo arithmetic promotion in any
arithmetic operation. However, since the final variables are
resolved at compile time, the compiler will not enforce rigerous
type-checking.
To explain what I mean, consider the following example
<PRE>
byte a = 10 ;
byte b = 20 ;
byte c = a + b ; // Error

final byte a = 10 ;
final byte b = 20 ;
byte c = a + b ; // No Error
</PRE>
In the first case, though a+b can indeed be assigned to c
without losing value, compiler looks at the type of c and raises
incompatible type (between int and byte ) error.
In the second case however, because the variables are declared as final, compiler knows their value cannot be changed and hence
takes them for the "face value" ignoring their type atleast for
the duration of applying the addition. In fact this expression
evaluates to c = 10 + 20 just after compilation.
Hope this helps.
Ajith
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ajith Kallambella:
Let me try..
Explicit casting required wherever narrowing conversion is required.
The famous examples,
<PRE>
byte a = 1 ;
byte b = 2 ;
byte c = a + b ; // Error!
int i = 1 ;
byte j = 1 ; // Error WHY WOULD THIS BE AN ERROR?
final int k = 1 ;
byte m = k ; // No Error
</PRE>
I am sure this covers most of it, though it may not be complete.
Feel free to comment/balk/scream/thrash me if I am wrong!!
Ajith


Ajith:
small correction....
please take a look at the foll line why would
this be an error. Were you thinking of saying:
byte j = i; // not numerical 1
Regds.
- satya
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Satya,
It is infact given as i and not 1. Do you read it right?....just kidding Thanks for pointing out that was a typo. Fixed it.
Ajith
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My opinion is that when you use ++ operator, it never gets promoted, as in the case of Roundup. Given below is a small program that proves it and byte folr all the variables.
import java.lang.reflect.*;
class test
{
byte c=10;
byte d =c++;
byte e = 127;
byte r= e++;
test() throws Exception
{
Class cl = Class.forName("test");
Field flds[] = cl.getDeclaredFields();
System.out.println(flds[0].getType());
System.out.println(flds[1].getType());
System.out.println(flds[2].getType());
System.out.println(flds[3].getType());
}
static public void main(String[]p) throws Exception
{
new test();
}
}
 
Sushma
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
A/c to Ajith's post, " For ++ and -- operators, compiler promotes the numbers to int, and
after the operation, narrows the result to fit into the operand type."------i think, this explains the reason why the above program prints out byte.
Correct me if i'm wrong.
Sushma
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!