tags:

views:

1648

answers:

9

For example, when I'm dividing two ints and want a float returned, I superstitiously write something like this:

int a = 2, b = 3;
float c = (float)a / (float)b;

If I do not cast a and b to floats, it'll do integer division and return an int.

Similarly, if I want to multiply a signed 8-bit number with an unsigned 8-bit number, I will cast them to signed 16-bit numbers before multiplying for fear of overflow:

u8 a = 255;
s8 b = -127;
s16 = (s16)a * (s16)b;

How exactly does the compiler behave in these situations when not casting at all or when only casting one of the variables? Do I really need to explicitly cast all of the variables, or just the one on the left, or the one on the right?

+2  A: 

Division of integers: cast any one of the operands, no need to cast them both. If both operands are integers the division operation is an integer division, otherwise it is a floating-point division.

As for the overflow question, there is no need to explicitly cast, as the compiler implicitly does that for you:

#include <iostream>
#include <limits>

using namespace std;
int main()
{
    signed int a = numeric_limits<signed int>::max();
    unsigned int b = a + 1; // implicit cast, no overflow here
    cout << a << ' ' <<  b << endl;
    return 0;
}
wilhelmtell
+4  A: 

You can just cast one of them. It doesn't matter which one though.

Whenever the types don't match, the "smaller" type is automatically promoted to the "larger" type, with floating point being "larger" than integer types.

Matthew Crumley
A: 

In the case of the floating-point division, as long as one variable is of a floating-point datatype (float or double), then the other variable should be widened to a floating-point type, and floating-point division should occur; so there's no need to cast both to a float.

Having said that, I always cast both to a float, anyway.

mipadi
A: 

I think as long as you are casting just one of the two variables the compiler will behave properly (At least on the compilers that I know).

So all of:

float c = (float)a / b;

float c = a / (float)b;

float c = (float)a / (float)b;

will have the same result.

+7  A: 

In general, if operands are of different types, the compiler will promote all to the largest or most precise type:

If one number is...   And the other is...    The compiler will promote to...
-------------------   -------------------    -------------------------------
char                  int                    int
signed                unsigned               unsigned
char or int           float                  float
float                 double                 double

Examples:

char       + int             ==> int
signed int + unsigned char   ==> unsigned int
float      + int             ==> float

Beware, though, that promotion occurs only as required for each intermediate calculation, so:

4.0 + 5/3  =  4.0 + 1 = 5.0

This is because the integer division is performed first, then the result is promoted to float for the addition.

Adam Liss
good point about lazy implicit casts
wilhelmtell
I think you meant "signed + unsigned = signed"?
Kasprzol
Kasprzol: The rules promote signed vars to unsigned; promotion is generally from smaller to larger types, then from signed to unsigned.
Adam Liss
+1  A: 

Then there are older brain-damaged types like me who, having to use old-fashioned languages, just unthinkingly write stuff like

int a;
int b;
float z;

z = a*1.0*b;

Of course this isn't universal, good only for pretty much just this case.

DarenW
A: 

Having worked on safety-critical systems, i tend to be paranoid and always cast both factors: float(a)/float(b) - just in case some subtle gotcha is planning to bite me later. No matter how good the compiler is said to be, no matter how well-defined the details are in the official language specs. Paranoia: a programmer's best friend!

DarenW
+11  A: 

Question 1: Float division

int a = 2, b = 3;
float c = static_cast<float>(a) / b;  // need to convert 1 operand to a float

Question 2: How the compiler works

Five rules of thumb to remember:

  • Arithmetic operations are always performed on values of the same type.
  • The result type is the same as the operands (after promotion)
  • The smallest type arithmetic operations are performed on is int.
  • ANSCI C (and thus C++) use value preserving integer promotion.
  • Each operation is done in isolation.

The ANSI C rules are as follows:
Most of these rules also apply to C++ though not all types are officially supported (yet).

  • If either operand is a long double the other is converted to a long double.
  • If either operand is a double the other is converted to a double.
  • If either operand is a float the other is converted to a float.
  • If either operand is a unsigned long long the other is converted to unsigned long long.
  • If either operand is a long long the other is converted to long long.
  • If either operand is a unsigned long the other is converted to unsigned long.
  • If either operand is a long the other is converted to long.
  • If either operand is a unsigned int the other is converted to unsigned int.
  • Otherwise both operands are converted to int.

Overflow

Overflow is always a problem. Note. The type of the result is the same as the input operands so all the operations can overflow, so yes you do need to worry about it (though the language does not provide any explicit way to catch this happening.

As a side note:
Unsigned division can not overflow but signed division can.

std::numeric_limits<int>::max() / -1  // No Overflow
std::numeric_limits<int>::min() / -1  // Will Overflow
Martin York
Nice overview - maybe use the term "promoted" iso "converted"?
xtofl
"Overflow is always a problem". Except for that once-in-a-lifetime case where modulo arithmetic is what you actually want.
Steve Jessop
A: 

Do you need to cast one or two sides? The answer isn't dictated by the compiler. It has to know the exact, precse rules. Instead, the answer should be dictated by the person who will read the code later. For that reason alone, cast both sides to the same type. Implicit truncation might be visible enough, so that cast could be redundant.

e.g. this cast float->int is obvious.

int a = float(foo()) * float(c);
MSalters