Question

I am bit confused about implicit type conversion. Given the following program

   float x = 4.23423451;
   double y = 4.23423451;

   float z = 101.9876;

   float res1 = x * z;
   float res2 = y * z;

   std::cout << "res1 & res2 " << res1 << "  & " << res2 << std::endl;
   std::cout << "equality " << (res1 == res2) << std::endl;

The output was

   res1 & res2 431.839  & 431.839
   equality 1

My question is “Will the equality be always true for any value of x, y & z (x = y) and also for any compiler?”

In

res2 = y * z;

Will the variable “y” be type-casted to float or variable “z” be type-casted to double?

Answer 1

See my comments.

This is well-defined. The intermediate expression for z will undergo widening into double, so y * z will be a double expression. An implicit narrowing conversion will then convert it to float for storing in res2. This same narrowing applies to res1.

This is reflected by §5¶9 Expressions [expr] of the C++11 standard.

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

…

• Otherwise, if either operand is double, the other shall be converted to double.
• Otherwise, if either operand is float, the other shall be converted to float.

…

This, however, does not sure that the equality will hold.

That being said, res1 need not necessarily be equivalent to res2 — it is highly dependent on the precision of float and double in the environment. The two literals could potentially not even be equal — 4.23423451f not need even be equivalent to 4.23423451. You can not be sure that static_cast<double>(static_cast<float>(4.23423451)) will be equal to 4.23423451.

See §5.17¶3 Assignment and compound assignment operators [expr.ass].

If the left operand is not of class type, the expression is implicitly converted (Clause 4) to the cv-unqualified type of the left operand.

§4 Standard conversions [conv] states as follows:

Standard conversions are implicit conversions with built-in meaning. Clause 4 enumerates the full set of such conversions. A standard conversion sequence is a sequence of standard conversions in the following order:

…

• Zero or one conversion from the following set: integral promotions, floating point promotion, integral conversions, floating point conversions, floating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions.

As elaborated in §4.6 Floating point promotion [conv.fpprom],

1. A prvalue of type float can be converted to a prvalue of type double. The value is unchanged.
2. This conversion is called floating point promotion.

… and §4.8 Floating point conversions [conv.double],

1. A prvalue of floating point type can be converted to a prvalue of another floating point type. If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values. Otherwise, the behavior is undefined.

2. The conversions allowed as floating point promotions are excluded from the set of floating point conversions.

The problem here is that we have multiple cases where our conversion is not promotion, but rather narrowing to a potentially lower-precision type (double to float).

Essentially, any time you convert double to float, you may potentially lose precision.