Unsigned and signed comparison

Unsigned and signed comparison - c++

Here is very simple code,
#include <iostream>
using namespace std;
int main() {
unsigned int u=10;
int i;
int count=0;
for (i=-1;i<=u;i++){
count++;
}
cout<<count<<"\n";
return 0;
}
The value of count is 0. Why?

Both operands of <= have to be promoted to the same type.
Evidently they are promoted to unsigned int (I don't have the rule from the standard in front of me, I'll look it up in a second). Since (unsigned int)(-1) <= u is false, the loop never executes.
The rule is found in section 5 (expr) of the standard, paragraph 10, which states (I've highlighted the rule which applies here):
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. 60 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.

During the comparison (i <= u), i is upgraded to an unsigned integer, and in the process -1 is converted to UINT_MAX.
A conversion of a negative number to an unsigned int will add (UINT_MAX + 1) to that number, so -1 becomes UINT_MAX, -2 becomes UINT_MAX - 1, etc.
If you think about it, one had to be converted to the other in order for the comparison to even work, and as a rule the compiler converts the signed value to unsigned. In this case, of course, it'd make more sense to convert the unsigned value to signed instead, but the compiler can't just decide to follow a different spec based on what you intend. You should explicitly cast the unsigned int to signed (or just have it as signed all along) here.

Its because -1 is casted as an unsigned int, so the for loop code is never executed.
Try compiling with -Wall -Wextra so you can get the respective warnings (if not getting them so far, and compiling with g++)
http://en.wikipedia.org/wiki/Two's_complement

This is because i is promoted to an unsigned value before comparison. This will set it to the value of UINT_MAX, which on a 32 bit machine equals to 4294967295. So your loop is essentially the same as:
// will never run
for (i = 4294967295; i <= u; i++) {
count++;
}

On a system where an integer is stored in 4 bytes, I believe that the value of -1 equals the value of 2147483649 (1000 0000 0000 0000 0000 0000 0000 0001) - It's 1 with the MSB set to 1 to indicate it's negative.

Related

What governs the type of the expression? [duplicate]

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

Arithmetic operations on unsigned variables produce signed values, is it standard behavior?

Subtracting two unsigned variables I expect an unsigned result. I do realize that overflow happens but that's ok, I'm actually counting on it.
Seems like that's not the case when the result needs to be used in another operation. Is this standard or undefined behavior?
uint8_t n1 = 255;
uint8_t z = 0;
uint8_t n = 1;
printf("n1 is %" PRIu8 "\n", n1);
printf("z - n is %" PRIu8 "\n", z - n);
printf("n1 < z: %s\n", n1 < z ? "yes" : "no");
printf("z - n < z: %s\n", z - n < z ? "yes" : "no");
printf("(uint8_t)(z - n) < (uint8_t)z: %s\n", (uint8_t)(z - n) < (uint8_t)z ? "yes" : "no");
Output:
n1 is 255
z - n is 255
n1 < z: no
z - n < z: yes
(uint8_t)(z - n) < (uint8_t)z: no

When the variables are of type uint8_t, they are both promoted to (signed) int and then the subtraction occurs between the promoted values, yielding a (signed) int value. It is mandated behaviour.
In C11, §6.3.1.8 Usual arithmetic conversions says:
Many operators that expect operands of arithmetic type cause conversions and yield result types in a similar way. The purpose is to determine a common real type for the operands and result. For the specified operands, each operand is converted, without change of type domain, to a type whose corresponding real type is the common real type. Unless explicitly stated otherwise, the common real type is also the corresponding real type of the result, whose type domain is the type domain of the operands if they are the same, and complex otherwise. This pattern is called the usual arithmetic conversions:
First, if the corresponding real type of either operand is long double, the other operand is converted, without change of type domain, to a type whose corresponding real type is long double.
Otherwise, if the corresponding real type of either operand is double, the other operand is converted, without change of type domain, to a type whose corresponding real type is double.
Otherwise, if the corresponding real type of either operand is float, the other operand is converted, without change of type domain, to a type whose corresponding real type is float.62)
Otherwise, the integer promotions are performed on both operands. Then the following rules are applied to the promoted operands:
If both operands have the same type, then 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 is converted to the type of the operand with greater rank.
Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is 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, then 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.
See §6.3.1 Arithmetic operands and §6.3.1.1 Boolean, characters, and integers for more information about 'integer promotions'.
The following may be used in an expression wherever an int or unsigned int may be used:
An object or expression with an integer type (other than int or unsigned int) whose integer conversion rank is less than or equal to the rank of int and unsigned int.
A bit-field of type _Bool, int, signed int, or unsigned int.
If an int can represent all values of the original type (as restricted by the width, for a bit-field), the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.58) All other types are unchanged by the integer promotions.
The term 'rank' is defined in that section; it's complex, but basically, long has a higher rank than int, and int has a higher rank than char.
The rules are undoubtedly slightly different in C++, but the net result is essentially the same.

In arithmetic, integers narrower than int are promoted to int, and then arithmetic on them is done in the int type. If you store the result in a uint8_t or other type, it will be converted to that type. But if you pass it to printf, it will remain an int.
In C, the usual arithmetic conversions for real numbers are:
If either type is long double, the other is converted to long double.
Otherwise, if either is double, the other is converted to double.
Otherwise, if either is float, the other is converted to float.
Otherwise, the integer promotions are performed on each operand. Then:
If both operands have the same time, no further conversion is performed.
Otherwise, if both are signed or both are unsigned, the narrower1 operand is converted to the wider operand.
Otherwise, if the unsigned operand is as wide as or wider than the other, the signed operand is converted to the unsigned type.
Otherwise, if the signed type can represent all the values of the unsigned type, the unsigned operand is converted to the signed type.
Otherwise, both operands are converted to the unsigned type corresponding to the signed type.
The integer promotions are:
If a type is wider1 than unsigned int, it is not changed.
Otherwise, if an int can represent all values of the type, the value is converted to int.
Otherwise, the value is converted to unsigned int.
Footnote
1 The C standard actually uses a technical classification of rank, which involves further details. It affects C implementations where multiple integer types can have the same width, aside from just being signed and unsigned.

unsigned int / signed int / long long: inexplicable output

So I was playing around with types and I came out with this weird result below. Debugging it made no sense, and then the only result was to check out the c++ spects, which didn't helped much. I was wondering if you might know what is happening here exactly, and if it is 32Bit and/or 64Bit specific issue.
#include <iostream>
using namespace std;
int main() {
unsigned int u = 1;
signed int i = 1;
long long lu = -1 * u;
long long li = -1 * i;
std::cout<<"this is a weird " << lu << " " << li << std::endl;
return 0;
}
Where the output is
this is a weird 4294967295 -1

The key observation is that the expression -1 * u is of type unsigned int. That is because the rules for arithmetic conversions* say that if one operand is unsigned int and the other is signed int, then the latter operand is converted to unsigned int. The arithmetic expressions are ultimately only defined for homogeneous operands, so the conversions happen before the operation proper.
The result of the conversion of -1 to unsigned int is a large, positive number, which is representable as a long long int, and which is the number you see in the output.
Currently, that's [expr]/(11.5.3).

The type of -1 is signed int. When you perform an arithmetic operation between objects of different fundamental type, one or both of the arguments will be converted so that both have the same type. (For non-fundamental types, there may be operator overloads for mixed operands). In this case, the signed value is converted to unsigned, following the conversion rules †.
So, -1 was converted to unsigned. But negative numbers cannot be represented by unsigned types. What happens, is that the resulting value will be the smallest positive value that can be represented by the unsigned type, that is congruent with the original signed value modulo the maximum value representable by unsigned type. Which on your platform happens to be 4294967295.
†The rules ([expr], standard draft):
... rules that apply to non-integers ...
Otherwise, the integral promotions (4.5) shall be performed on both operands.61 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. (this applies to your case)
— 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.

The evaluation of
-1 * i
is trivial multiplication of two int types: nothing strange there. And a long long must be capable of holding any int.
First note is there is no such thing as a negative literal in C++, so
-1 * u
is evaluated as (-1) * u due to operator precedence. The type of (-1) must be int. But this will be converted to unsigned int due to C++'s rule of argument conversion as the other argument is an unsigned int In doing that it is converted modulo UINT_MAX + 1, so you end up with UINT_MAX multiplied by 1, which is the number you observe, albeit converted to a long long type.
As a final note, the behaviour of this conversion is subject to the rules of conversion from an unsigned to a signed type: if unsigned int and long long were both 64 bits on your platform then the behaviour is implementation-defined.

The bit pattern "0xFFFFFFFF" corresponds with "-1" when interpreted as a 32b signed integer and corresponds with "4294967295" when interpreted as a 32b unsigned integer.
If used -2 the result is "4294967294"
If used -3 the result is "4294967293"
If used -4 the result is "4294967292"
....

How to know what data type an operation will return in C++ [duplicate]

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 ]

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.)

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

Implicit type conversion rules in C++ operators

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 ]

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.)

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

We Keep Coding

c++ django amazon-web-services regex python-2.7 google-cloud-platform list unit-testing opengl ember.js