Type Casting for return statements, any gains??

[lostInC]

Is the following type cast really needed???

float myFunction(float inVal)
{
//does this type cast of a float really gain anything??
return (float) (inVal * 25.25687);
}

[FillYourBrain]

I don't believe so. your return value is a float, your original value is a float. if the compiler sees the 25.25687 as a double that's the only thing I can see as an issue. I say leave it out. I could be wrong.

[lostInC]

Would the compiler and/or target platform be an issue?

[bman1176]

I don't see any gains. It does floating-point arithmetic and then the return type is a float.

What is the overhead of type casting?

[Polymorphic OOP]

Originally posted by vVv
>What is the overhead of type casting?

There's none, it's merely a way to tell the compiler how to view the data. And in this particular case there aren't even any changes to the regular treatment without a cast, because both variables are floats already.

No, actually they both weren't floats. The value he used is a double not a float and so the value of the expression on the right hand side of the equals was double not float. You'd typecast to float for clarity -- it should automatically make the conversion however most compilers will warn you that you will lose precission. If you explicitly typecast, the compiler understands that that is truely what you wanted to do and most likely won't display a warning. Anytime you are doing arithmetic that results in a datatype of more precission than that of the variable you are storing the value to it's a good idea to explicitly type-cast, though it is certainly not necissary.

[Mister C]

Actually, to cast you should use static_cast<>() syntax instead of the older C way.

[quzah]

Originally posted by Mister C
Actually, to cast you should use static_cast<>() syntax instead of the older C way.

Didn't we just have this debate? Let's not go through this again.

Quzah.

[Mister C]

OK, fine. Well at least we all know it is int main()!!!