Quote:Original post by Archi
float x = (float)(a/b) is the way I did

I don't think that'll work. The integer divide would happen before the float cast.

I think the OP would have known why it was 1 if he was using integer variables (cause he seemed to already understand the fact that his type being float was important) ... so it seems he was only surprised by the fact that:

float f = 300/400;

is using an integer 300 and an integer 400 when the compiler could clearly see the result is float ...

I think the thing he (and many others) didn't know is that all literals are inheirently typed ... all the time - even in #define statements.

100 is always an integer, and (if memory serves) 100.0 is always a double (correct me if i'm wrong here).

Hence the reason you see:

100.0f (makes it be a float instead of a double)
100L (long instead of int)
100U (unsigned instead of int)

and also of course
0144 // 100 as an octal number
0x64 // 100 as a hex constand

Quote:
I think the OP would have known why it was 1 if he was using integer variables (cause he seemed to already understand the fact that his type being float was important) ... so it seems he was only surprised by the fact that:

float f = 300/400;

is using an integer 300 and an integer 400 when the compiler could clearly see the result is float ...

but

float f = 25/5;

wouldn't be so obvious would it? hence the convention...

what convention? I think there was a minor misunderstanding .. I know the reasons why the C / C++ compiler acts the way it does, and believe it makes complete sense. And here's the real reason - if the user WANTS this float to be initialize based on integral arithmatic, he/she needs that option.

All I was saying in my last post was: I think the OP and others like him need to be informed about the fact that all literals are typed (and therefore follow almost exactly the same rules as if they we're variables of their type), and how to select their type, more than about types, casts, and expression evaluation in general (most C/C++ people learn the basic expression evaluation fairly early).

It's not a function, it's a constructor call (although it may be refered to as a function style cast) - it is only available on types which implement a constructor taking the single parameter of the appropriate type ...

Quote:Original post by Xai
It's not a function, it's a constructor call (although it may be refered to as a function style cast) - it is only available on types which implement a constructor taking the single parameter of the appropriate type ...

Hence more appropriate in generic programming.