I have the following piece of code:
#include <cstdint>
template <typename T>
T test(T a, T b)
{
float aabb = reinterpret_cast<float>(a - b);
}
int main(int argc, const char *argv[])
{
std::uint8_t a8, b8;
test(a8, b8);
return 0;
}
I know that the reinterpret_cast<float> can't work and that it gives an error at compile time. I am using that error so that the compiler tells me the type of a - b.
The problem is that in this case, it says that the type of a - b is int when both of them are uint8_t (unsigned char). The same happens with uint16_t. But not with uint32_t which it says that a - b is unsigned int.
So, my question is: Is this intended behaviour (that unsigned char - unsigned char gives an int), or is this some kind of weird compiler bug (tested with both GCC and clang) ?
Yes, this is expected, as part of the so-called usual arithmetic conversions combined with the rules for integral promotion.
The exact wording changed between C++03 and C++11, but the end result is the same in this case.
[C++03: 4.5/1]: An rvalue of type char, signed char, unsigned char, short int, or unsigned short int can be converted to an rvalue of type int if int can represent all the values of the source type; otherwise, the source rvalue can be converted to an rvalue of type unsigned int.
[C++03: 4.5/5]: These conversions are called integral promotions.
[C++03: 5/9]: 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:
If either operand is of type long double, the other shall be converted to long double.
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.
Otherwise, the integral promotions (4.5) shall be performed on both operands.54
Then, if either operand is unsigned long the other shall be converted to unsigned long.
Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the values of an unsigned int, the unsigned int shall be converted to a long int; otherwise both operands shall be converted to unsigned long int.
Otherwise, if either operand is long, the other shall be converted to long.
Otherwise, if either operand is unsigned, the other shall be converted to unsigned.
[Note: otherwise, the only remaining case is that both operands are int ]
[C++11: 4.5/1]: A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.
[C++11: 4.5/7]: These conversions are called integral promotions.
[C++11: 5.9]: 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:
If either operand is of scoped enumeration type (7.2), no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
If either operand is of type long double, the other shall be converted to long double.
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.
Otherwise, the integral promotions (4.5) shall be performed on both operands.59 Then the following rules shall be applied to the promoted operands:
If both operands have the same type, no further conversion is needed.
Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank shall be converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type shall be converted to the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall be converted to the type of the operand with signed integer type.
Otherwise, both operands shall be converted to the unsigned integer type corresponding to the type of the operand with signed integer type.
Related
When using a ternary operator within list initialization, what causes the implicit conversion of int to unsigned int (and similarly for long long) but not short to unsigned short (and similarly for char).
Specifically, I am surprised that the i32v2 function compiles fine whereas the others do not:
unsigned short f16(unsigned short x);
unsigned int f32(unsigned int x);
void i16(short value) {
unsigned short encoded{value}; // narrowing, makes sense
}
void i32(int value) {
unsigned int encoded{value}; // narrowing, makes sense
}
void i16v2(short value) {
unsigned short encoded{false ? value : f16(value)}; // narrowing, makes sense
}
void i32v2(int value) {
unsigned int encoded{false ? value : f32(value)}; // not narrowing, huh?
}
Complete example here: https://godbolt.org/z/fVTcrr
I am guessing the ternary operator implicitly converts int to unsigned int but I do not understand why it is unable to convert short to unsigned short similarly.
I would expect, if it was possible for int, then the ternary operator should also be able to convert any of the other signed types to the unsigned when possible:
If the destination type is unsigned, the resulting value is the smallest unsigned value equal to the source value modulo 2n
where n is the number of bits used to represent the destination type.
(https://en.cppreference.com/w/cpp/language/implicit_conversion)
Can someone explain this behavior, and if possible, reference the standard or applicable cppreference page?
The standard says (quotes from latest draft):
[expr.cond]
Lvalue-to-rvalue, array-to-pointer, and function-to-pointer standard conversions are performed on the second and third operands.
After those conversions, one of the following shall hold:
The second and third operands have the same type; ... [does not apply]
The second and third operands have arithmetic [applies] or enumeration type; the usual arithmetic conversions are performed to bring them to a common type, and the result is of that type.
...
[expr.arith.conv]
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:
If either operand is of scoped enumeration type ... [does not apply]
If either operand is of type long double ... [does not apply]
Otherwise, if either operand is double ... [does not apply]
Otherwise, if either operand is float ... [does not apply]
Otherwise, the integral promotions ([conv.prom]) shall be performed on both operands.
Then the following rules shall be applied to the promoted operands:
...
[conv.prom]
A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t [applies] whose integer conversion rank ([conv.rank]) is less than the rank of int [applies] can be converted to a prvalue of type int if int can represent all the values of the source type [evidently applies1]; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.
These conversions are called integral promotions.
So, in the case of i16v2, the second and third operands are short and unsigned short. Both evidently1 promote to int on your system, and the int result of the conditional operator is then used to initialise the unsigned short.
In the case of i32v2, no promotions apply and the common type of int and unsigned int is unsigned int.
1 I say evidently, because technically, unsigned short could promote to unsigned int on some exotic system where their size is the same, in which case int couldn't represent all values of unsigned short. The outcome that you observe shows that is not the case for your system, which is to be expected.
Note that for false ? value : f16(value), integral_promotion is performed on the operands firstly. For arithmetic operator,
If the operand passed to an arithmetic operator is integral or unscoped enumeration type, then before any other action (but after lvalue-to-rvalue conversion, if applicable), the operand undergoes integral promotion.
and
The following implicit conversions are classified as integral
promotions:
signed char or signed short can be converted to int;
That means the return type of false ? value : f16(value) is int, then causes the narrowing conversion to unsigned short.
On the other hand, the return type, i.e. the common type for false ? value : f32(value) is unsigned int, then unsigned int encoded{false ? value : f32(value)}; is fine.
Otherwise, the operand has integer type (because bool, char, char8_t,
char16_t, char32_t, wchar_t, and unscoped enumeration were promoted at
this point) and integral conversions are applied to produce the common
type, as follows:
...
Otherwise, if the unsigned operand's conversion rank is greater or equal to the conversion rank of the signed operand, the signed operand
is converted to the unsigned operand's type.
For long or long long, they won't be promoted to int, then they don't have such issues.
I was writing some code recently that was actually supposed to test other code, and I stumbled upon a surprising case of integer promotion. Here's the minimal testcase:
#include <cstdint>
#include <limits>
int main()
{
std::uint8_t a, b;
a = std::numeric_limits<std::uint8_t>::max();
b = a;
a = a + 1;
if (a != b + 1)
return 1;
else
return 0;
}
Surprisingly this program returns 1. Some debugging and a hunch revealed that b + 1 in the conditional was actually returning 256, while a + 1 in assignment produced the expected value of 0.
Section 8.10.6 (on the equality/ineuqlity operators) of the C++17 draft states that
If both operands are of arithmetic or enumeration type, the usual arithmetic conversions are performed on
both operands; each of the operators shall yield true if the specified relationship is true and false if it is
false.
What are "the usual arithmetic conversions", and where are they defined in the standard? My guess is that they implicitly promote smaller integers to int or unsigned int for certain operators (which is also supported by the fact that replacing std::uint8_t with unsigned int yields 0, and further in that the assignment operator lacks the "usual arithmetic conversions" clause).
What are "the usual arithmetic conversions", and where are they defined in the standard?
[expr.arith.conv]/1
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:
(1.1) If either operand is of scoped enumeration type, no conversions
are performed; if the other operand does not have the same type, the
expression is ill-formed.
(1.2) If either operand is of type long double, the other shall be
converted to long double.
(1.3) Otherwise, if either operand is double, the other shall be
converted to double.
(1.4) Otherwise, if either operand is float, the other shall be
converted to float.
(1.5) Otherwise, the integral promotions ([conv.prom]) shall be
performed on both operands.59 Then the following rules shall be
applied to the promoted operands:
(1.5.1) If both operands have the same type, no further conversion is
needed.
(1.5.2) Otherwise, if both operands have signed integer types or both
have unsigned integer types, the operand with the type of lesser
integer conversion rank shall be converted to the type of the operand
with greater rank.
(1.5.3) Otherwise, if the operand that has unsigned integer type has
rank greater than or equal to the rank of the type of the other
operand, the operand with signed integer type shall be converted to
the type of the operand with unsigned integer type.
(1.5.4) Otherwise, if the type of the operand with signed integer type
can represent all of the values of the type of the operand with
unsigned integer type, the operand with unsigned integer type shall be
converted to the type of the operand with signed integer type.
(1.5.5) Otherwise, both operands shall be converted to the unsigned
integer type corresponding to the type of the operand with signed
integer type.
59) As a consequence, operands of type bool, char8_t, char16_t,
char32_t, wchar_t, or an enumerated type are converted to some
integral type.
For uint8_t vs int (for operator+ and operator!= later), #1.5 is applied, uint8_t will be promoted to int, and the result of operator+ is int too.
On the other hand, for unsigned int vs int (for operator+), #1.5.3 is applied, int will be converted to unsigned int, and the result of operator+ is unsigned int.
Your guess is correct. Operands to many operators in C++ (e.g., binary arithmetic and comparison operators) are subject to the usual arithmetic conversions. In C++17, the usual arithmetic conversions are specified in [expr]/11. I'm not going to quote the whole paragraph here because it's rather large (you can just click on the link), but for integral types, the usual arithmetic conversions boil down to integral promotions being applied followed by effectively some more promoting in the sense that if the types of the two operands after the initial integral promotions are not the same, the smaller type is converted to the larger one of the two. The integral promotions basically mean that any type smaller than an int will be promoted to int or unsigned int, whichever of the two can represent all possible values of the original type, which is mainly what is causing the behavior in your example.
As you have already figured out yourself, in your code, the usual arithmetic conversions happen in a = a + 1; and, most noticeably, in the condition of your if
if (a != b + 1)
…
where they cause b to be promoted to int, making the result of b + 1 to be of type int, as well as a being promoted to int and the !=, thus, happening on values of type int, which causes the condition to be true rather than false…
char cval;
short sval;
long lval;
sval + cval; // sval and cval promoted to int
cval + lval; // cval converted to long
This is a piece of code on C++ Primer.
I know sval+cval generates an int type according to
convert the small integral types to a larger integral type. The types
bool, char, signed char, unsigned char, short, and unsigned short are
promoted to int if all possible values of that type fit in an int.
But for the last one I couldn't understand why it uses "converted". Why is cval not promoted to int first and then the int converted (or maybe promoted I'm not sure whether promoted can be used from int to long because I only see definition of promotion on smaller type to int) to long. I didn't see any explanation or examples on char straightly to long in that part of the book. Is there any thing wrong with my understanding?
I'm quite new at C++, someone please enlighten me! Many thanks in advance!
The additive operators perform what is called the usual arithmetic conversion on their operands which can include integral promotions and then after that we can have further conversions. The purpose is to yield a common type and if the promotions do not accomplish that then a further conversion is required.
This is covered in section 5 [expr] of the draft C++ standard which says (emphasis mine):
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 follow
and includes the following bullet:
Otherwise, the integral promotions (4.5) shall be performed on both operands.61 Then the following
rules shall be applied to the promoted operands:
which has the following bullets:
If both operands have the same type, no further conversion is needed
Otherwise, if both operands have signed integer types or both have unsigned integer types, the
operand with the type of lesser integer conversion rank shall be converted to the type of the
operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the
rank of the type of the other operand, the operand with signed integer type shall be converted to
the type of the operand with unsigned integer type.
Otherwise, if the type of the operand with signed integer type can represent all of the values of
the type of the operand with unsigned integer type, the operand with unsigned integer type shall
be converted to the type of the operand with signed integer type.
Otherwise, both operands shall be converted to the unsigned integer type corresponding to the
type of the operand with signed integer type.
So in the first case after promotions they both have the same type(int) so no further conversion is needed.
In the second case after promotions they do not(int and long) so a further conversion is required.
From the C++11 Standard:
4 Standard conversions
1 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: lvalue-to-rvalue conversion, array-to-pointer conversion, and function-to-pointer conversion.
— 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.
— Zero or one qualification conversion.
In the expression,
cval + lval;
since cval is not of type long, it has to be converted to long. However, in the process of applying the standard conversions, integral promotion comes ahead of conversions. Hence, cval is promoted to an int first before being converted to a long.
From the standard, I was trying to understand which type the expression will end up to be:
bool myBool;
[...]
uint8_t(255) * (myBool);
Am I guaranteed that myBool will be casted to uint8_t (a.k.a. unsigned char), or the whole result might be int?
Useful link: bool to int conversion
Both operands will be promoted to int, and that will be the result type.
In general, integer operands are promoted to at least int, or a larger type if necessary, and arithmetic is not performed on smaller types. This is described by C++11 4.5 (Integral promotions).
For uint8_t:
1/ A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.
If it exists, then all 8-bit uint8_t values are representable by int (which must be at least 16 bits), so int is the promoted type.
For bool:
6/ A prvalue of type bool can be converted to a prvalue of type int, with false becoming zero and true becoming one.
So that is also promoted to int, giving an overall result type of int.
From the document you linked to:
5 Expressions
9 Many binary operators that expect operands of arithmetic or enumera-
tion 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, the integral promotions (conv.prom) shall be performed
on both operands.1)
and
4.5 Integral promotions
1 An rvalue of type char, signed char, unsigned char, short int, or
unsigned short int can be converted to an rvalue of type int if int
can represent all the values of the source type; otherwise, the source
rvalue can be converted to an rvalue of type unsigned int
...
4 An rvalue of type bool can be converted to an rvalue of type int, with
false becoming zero and true becoming one.
In your case, both the LHS and RHS will be promoted to int before the arithmetic operation and the resultant will be of type int.
I want to be better about knowing when I should cast. What are the implicit type conversion rules in C++ when adding, multiplying, etc. For example,
int + float = ?
int * float = ?
float * int = ?
int / float = ?
float / int = ?
int / int = ?
int ^ float = ?
et cetera...
Will the expression always be evaluated as the more precise type? Do the rules differ for Java?
Please correct me if I have worded this question inaccurately.
In C++ operators (for POD types) always act on objects of the same type.
Thus if they are not the same one will be promoted to match the other.
The type of the result of the operation is the same as operands (after conversion).
if:
either is long double other is promoted > long double
either is double other is promoted > double
either is float other is promoted > float
either is long long unsigned int other is promoted > long long unsigned int
either is long long int other is promoted > long long int
either is long unsigned int other is promoted > long unsigned int
either is long int other is promoted > long int
either is unsigned int other is promoted > unsigned int
either is int other is promoted > int
Otherwise:
both operands are promoted to int
Note. The minimum size of operations is int. So short/char are promoted to int before the operation is done.
In all your expressions the int is promoted to a float before the operation is performed. The result of the operation is a float.
int + float => float + float = float
int * float => float * float = float
float * int => float * float = float
int / float => float / float = float
float / int => float / float = float
int / int = int
int ^ float => <compiler error>
Arithmetic operations involving float results in float.
int + float = float
int * float = float
float * int = float
int / float = float
float / int = float
int / int = int
For more detail answer. Look at what the section §5/9 from the C++ Standard says
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:
— If either operand is of type long
double, the other shall be converted
to long double.
— 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.
— Otherwise, the integral promotions
(4.5) shall be performed on both
operands.54)
— Then, if either operand
is unsigned long the other shall be
converted to unsigned long.
— Otherwise, if one operand is a long
int and the other unsigned int, then
if a long int can represent all the
values of an unsigned int, the
unsigned int shall be converted to a
long int; otherwise both operands
shall be converted to unsigned long
int.
— Otherwise, if either operand is
long, the other shall be converted to
long.
— Otherwise, if either operand
is unsigned, the other shall be
converted to unsigned.
[Note: otherwise, the only remaining case is
that both operands are int ]
Since the other answers don't talk about the rules in C++11 here's one. From C++11 standard (draft n3337) §5/9 (emphasized the difference):
This pattern is called the usual arithmetic conversions, which are defined as follows:
— If either operand is of scoped enumeration type, no conversions are performed; if the other operand does not have the same type, the expression is ill-formed.
— If either operand is of type long double, the other shall be converted to long double.
— 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.
— Otherwise, the integral promotions shall be performed on both operands. Then the following rules shall be applied to the promoted operands:
— If both operands have the same type, no further conversion is needed.
— Otherwise, if both operands have signed integer types or both have unsigned integer types, the
operand with the type of lesser integer conversion rank shall be converted to the type of the
operand with greater rank.
— Otherwise, if the operand that has unsigned integer type has rank greater than or equal to the
rank of the type of the other operand, the operand with signed integer type shall be converted to
the type of the operand with unsigned integer type.
— Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type shall
be converted to the type of the operand with signed integer type.
— Otherwise, both operands shall be converted to the unsigned integer type corresponding to the
type of the operand with signed integer type.
See here for a list that's frequently updated.
This answer is directed in large part at a comment made by #RafałDowgird:
"The minimum size of operations is int." - This would be very strange
(what about architectures that efficiently support char/short
operations?) Is this really in the C++ spec?
Keep in mind that the C++ standard has the all-important "as-if" rule. See section 1.8: Program Execution:
3) This provision is sometimes called the "as-if" rule, because an
implementation is free to disregard any requirement of the Standard
as long as the result is as if the requirement had been obeyed, as far
as can be determined from the observable behavior of the program.
The compiler cannot set an int to be 8 bits in size, even if it were the fastest, since the standard mandates a 16-bit minimum int.
Therefore, in the case of a theoretical computer with super-fast 8-bit operations, the implicit promotion to int for arithmetic could matter. However, for many operations, you cannot tell if the compiler actually did the operations in the precision of an int and then converted to a char to store in your variable, or if the operations were done in char all along.
For example, consider unsigned char = unsigned char + unsigned char + unsigned char, where addition would overflow (let's assume a value of 200 for each). If you promoted to int, you would get 600, which would then be implicitly down cast into an unsigned char, which would wrap modulo 256, thus giving a final result of 88. If you did no such promotions,you'd have to wrap between the first two additions, which would reduce the problem from 200 + 200 + 200 to 144 + 200, which is 344, which reduces to 88. In other words, the program does not know the difference, so the compiler is free to ignore the mandate to perform intermediate operations in int if the operands have a lower ranking than int.
This is true in general of addition, subtraction, and multiplication. It is not true in general for division or modulus.
If you exclude the unsigned types, there is an ordered
hierarchy: signed char, short, int, long, long long, float,
double, long double. First, anything coming before int in the
above will be converted to int. Then, in a binary operation,
the lower ranked type will be converted to the higher, and the
results will be the type of the higher. (You'll note that, from
the hierarchy, anytime a floating point and an integral type are
involved, the integral type will be converted to the floating
point type.)
Unsigned complicates things a bit: it perturbs the ranking, and
parts of the ranking become implementation defined. Because of
this, it's best to not mix signed and unsigned in the same
expression. (Most C++ experts seem to avoid unsigned unless
bitwise operations are involved. That is, at least, what
Stroustrup recommends.)
My solution to the problem got WA(wrong answer), then i changed one of int to long long int and it gave AC(accept). Previously, I was trying to do long long int += int * int, and after I rectify it to long long int += long long int * int. Googling I came up with,
1. Arithmetic Conversions
Conditions for Type Conversion:
Conditions Met ---> Conversion
Either operand is of type long double. ---> Other operand is converted to type long double.
Preceding condition not met and either operand is of type double. ---> Other operand is converted to type double.
Preceding conditions not met and either operand is of type float. ---> Other operand is converted to type float.
Preceding conditions not met (none of the operands are of floating types). ---> Integral promotions are performed on the operands as follows:
If either operand is of type unsigned long, the other operand is converted to type unsigned long.
If preceding condition not met, and if either operand is of type long and the other of type unsigned int, both operands are converted to type unsigned long.
If the preceding two conditions are not met, and if either operand is of type long, t he other operand is converted to type long.
If the preceding three conditions are not met, and if either operand is of type unsigned int, the other operand is converted to type unsigned int.
If none of the preceding conditions are met, both operands are converted to type int.
2 . Integer conversion rules
Integer Promotions:
Integer types smaller than int are promoted when an operation is performed on them. If all values of the original type can be represented as an int, the value of the smaller type is converted to an int; otherwise, it is converted to an unsigned int. Integer promotions are applied as part of the usual arithmetic conversions to certain argument expressions; operands of the unary +, -, and ~ operators; and operands of the shift operators.
Integer Conversion Rank:
No two signed integer types shall have the same rank, even if they have the same representation.
The rank of a signed integer type shall be greater than the rank of any signed integer type with less precision.
The rank of long long int shall be greater than the rank of long int, which shall be greater than the rank of int, which shall be greater than the rank of short int, which shall be greater than the rank of signed char.
The rank of any unsigned integer type shall equal the rank of the corresponding signed integer type, if any.
The rank of any standard integer type shall be greater than the rank of any extended integer type with the same width.
The rank of char shall equal the rank of signed char and unsigned char.
The rank of any extended signed integer type relative to another extended signed integer type with the same precision is implementation-defined but still subject to the other rules for determining the integer conversion rank.
For all integer types T1, T2, and T3, if T1 has greater rank than T2 and T2 has greater rank than T3, then T1 has greater rank than T3.
Usual Arithmetic Conversions:
If both operands have the same type, no further conversion is needed.
If both operands are of the same integer type (signed or unsigned), the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank.
If the operand that has unsigned integer type has rank greater than or equal to the rank of the type of the other operand, the operand with signed integer type is converted to the type of the operand with unsigned integer type.
If the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, the operand with unsigned integer type is converted to the type of the operand with signed integer type.
Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type. Specific operations can add to or modify the semantics of the usual arithmetic operations.
Whole chapter 4 talks about conversions, but I think you should be mostly interested in these :
4.5 Integral promotions
[conv.prom]
An rvalue of type char, signed char, unsigned char, short int, or unsigned short
int can be converted to an rvalue of type int if int can represent all the values of the source type; other-
wise, the source rvalue can be converted to an rvalue of type unsigned int.
An rvalue of type wchar_t (3.9.1) or an enumeration type (7.2) can be converted to an rvalue of the first
of the following types that can represent all the values of its underlying type: int, unsigned int,
long, or unsigned long.
An rvalue for an integral bit-field (9.6) can be converted to an rvalue of type int if int can represent all
the values of the bit-field; otherwise, it can be converted to unsigned int if unsigned int can rep-
resent all the values of the bit-field. If the bit-field is larger yet, no integral promotion applies to it. If the
bit-field has an enumerated type, it is treated as any other value of that type for promotion purposes.
An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true
becoming one.
These conversions are called integral promotions.
4.6 Floating point promotion
[conv.fpprom]
An rvalue of type float can be converted to an rvalue of type double. The value is unchanged.
This conversion is called floating point promotion.
Therefore, all conversions involving float - the result is float.
Only the one involving both int - the result is int :
int / int = int
The type of the expression, when not both parts are of the same type, will be converted to the biggest of both. The problem here is to understand which one is bigger than the other (it does not have anything to do with size in bytes).
In expressions in which a real number and an integer number are involved, the integer will be promoted to real number. For example, in int + float, the type of the expression is float.
The other difference are related to the capability of the type. For example, an expression involving an int and a long int will result of type long int.
Caveat!
The conversions occur from left to right.
Try this:
int i = 3, j = 2;
double k = 33;
cout << k * j / i << endl; // prints 22
cout << j / i * k << endl; // prints 0