• 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

Automatic typecasting

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wrote a program....

import java.io.*;


class anshul
{
public static void main()
{
int x;
float y =7.5f;
double z=3.0;
x=y/z;
System.out.println(x);
}

}

but compiler is giving me an error :possible loss of precision

why cant compiler do an automatic type conversion..as it is usually done..!!
 
Sheriff
Posts: 22787
131
Eclipse IDE Spring Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
int x;
float y =7.5f;
double z=3.0;
x=y/z;


y is a float. z is a double. Therefore, the result of y/z is a double as well. That may or may not (in this case will) have decimals. x is an int and cannot have any decimals. Therefore the assignment is not allowed directly. You'll need to use a cast: Note that the cast needs to be applied to the result of the division, hence the parentheses around y / z. Without these it would cast y to an int, divide it by z and the result would still be double.
 
Anshul Singhal
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Rob...But still I've a doubt

there is a concept of narrowing in automatic typecasting which states that if a larger type can be assigned to smaller type with a loss of information for e.g float can be assigned to int with the loss of decimal part. Why can't the same thing happen here??
 
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

The compiler itself saying why it will not automatically typecast: possible loss of precision, means some digits from your output is going to be truncated due to type 'int' that's why it will not cast it as usual.
 
Ranch Hand
Posts: 2066
IntelliJ IDE Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anshul Singhal wrote:Thank you Rob...But still I've a doubt

there is a concept of narrowing in automatic typecasting which states that if a larger type can be assigned to smaller type with a loss of information for e.g float can be assigned to int with the loss of decimal part. Why can't the same thing happen here??



Your question isn't clear. I think, you argue that, if the range is possible, there can be a narrowing conversion?

It is only for constants, not for expression. In your case, x=y/z; is a expression, and the compiler can't sure the range in compile time. So it flags Compilation error.
 
author
Posts: 23956
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Anshul Singhal wrote:
there is a concept of narrowing in automatic typecasting which states that if a larger type can be assigned to smaller type with a loss of information for e.g float can be assigned to int with the loss of decimal part. Why can't the same thing happen here??



First, let's clean up the terminology a bit. Implicit casting is probably what you meant -- and not automatic typecasting. Second, the concept that you are referring to are the special rules related to compile time constants.... Anyway, to answer your question.


To be considered as a compile time constant, strict rules must be adhered to. In this case, neither the variables y or z are compile time constants (although they have been assigned compile time constants). Hence, the expression is not a compile time constant, and hence, the rule doesn't apply.

And about the rule, the implicit casting rule is defined as part of the assignment conversion portion of the specification (section 5.2). And in the part about compile time constants... the value to be assigned must be of type byte, char, short, or int. This is not true in this case, even if the expression were a compile time constant.

Henry
 
Henry Wong
author
Posts: 23956
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Abimaran Kugathasan wrote:
It is only for constants, not for expression. In your case, x=y/z; is a expression, and the compiler can't sure the range in compile time. So it flags Compilation error.



As a side note, it is actually possible for variables and expressions to be considered compile time constants -- although in this example, it is not the case.

Henry
 
Abimaran Kugathasan
Ranch Hand
Posts: 2066
IntelliJ IDE Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Henry Wong wrote:

Abimaran Kugathasan wrote:
It is only for constants, not for expression. In your case, x=y/z; is a expression, and the compiler can't sure the range in compile time. So it flags Compilation error.



As a side note, it is actually possible for variables and expressions to be considered compile time constants -- although in this example, it is not the case.

Henry



Thanks Henry,



If the compiler knows the value at Compile time, then there can be implicit casting (narrowing conversion) as shown in the above code!
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic