# Type Conversion in C\+\+ and C\# Arithmetic Expressions

In arithmetic expressions, the types of operands can be converted to a common type\. Such conversions are described in the language standard, and in C\# they are much simpler than in C\+\+\. However, I'm not sure that many programmers know all the details\.

Perhaps you had situations when the type of an arithmetic expression turned out to be something different from what you had expected\. How well do you know the language standard? Test yourself by replacing _auto_ and _var_ with appropriate types in the expressions below and evaluating these expressions:

C\+\+ \(we're assuming that an [LP64](https://pvs-studio.com/en/blog/terms/0028/) data model is used\):

```cpp
void Test()
{
    unsigned char c1 = std::numeric_limits<unsigned char>::max();
    unsigned char c2 = std::numeric_limits<unsigned char>::max();
    int i1 = std::numeric_limits<int>::max();
    int i2 = std::numeric_limits<int>::max();
    unsigned int u1 = std::numeric_limits<unsigned int>::max();

    auto x = c1 + c2;
    auto y = i1 + i2;
    auto z = i1 + u1;
}
```

C\#:

```cpp
void Test()
{
    byte b1 = byte.MaxValue;
    byte b2 = byte.MaxValue;
    int i1 = int.MaxValue;
    int i2 = int.MaxValue;
    uint u1 = uint.MaxValue;

    var x = b1 + b2;
    var y = i1 + i2;
    var z = i1 + u1;
}
```

The answer is below the picture

![0386_TypeConversion/image1.png](https://import.viva64.com/docx/blog/0386_TypeConversion/image1.png)

C\+\+ \([LP64](https://pvs-studio.com/en/blog/terms/0028/)\):

```cpp
    int x = c1 + c2;          // = 510
    int y = i1 + i2;          // = -2
    unsigned int z = i1 + u1; // = 2147483646
```

C\#:

```cpp
    int x = b1 + b2;          // = 510
    int y = i1 + i2;          // = -2
    long z = i1 + u1;         // = 6442450942
```



Here is what follows from this test \- or rather the C\+\+ and C\# standards:

**1\.** **Evaluation** **of** _**x**_**\.** In an arithmetic expression, all the variables whose values can be represented with type _int_ will be converted to this type, so when adding two variables of type _char_, _unsigned_ _char_, _short_ _int_, or _unsigned_ _short_ _int_ in C\+\+, or variables of type _byte_, _sbyte_, _short_, or _ushort_ in C\#, the resulting value will be of type _int_ and no overflow will occur\. In our examples, the _x_ variable will take the value 510\.

**2\.** **Evaluation** **of** _**y**_**\.** If both arguments are of type _int_, no further type promotion will take place and an overflow is possible\. In C\+\+, an overflow leads to undefined behavior\. In C\#, the application will continue running by default\. You can use the _checked_ keyword or _/checked_ compiler switch to change its behavior so that it raises an OverflowException in the case of an overflow\. In our test, the _y_ variable will take the value \-2 both in C\+\+ and C\#\. However, remember that in C\+\+ we'll be dealing with undefined behavior, which may manifest itself in any way \- for example writing the number 100500 to _y_ or ending up with a stack overflow\.

**3\.** **Evaluation** **of** _**z**_**\.** The situation when one of the arguments is of type _int_ and the other is of type _unsigned_ _int_ in C\+\+ or _uint_ in C\# is handled differently by each standard\! In C\+\+, both arguments will be converted to type _unsigned_ _int_\. By the way, if an overflow occurs, it wouldn't be an undefined behavior\. In C\#, both arguments will be converted to type _long_ and no overflow will be ever possible\. It is the reason why we got different values for the _z_ variable in our programs in different languages\.

Now let's see what errors can be found in code written without taking type\-conversion rules into account\.

C\+\+ example:

```cpp
typedef unsigned int    Ipp32u;
typedef signed int      Ipp32s;

Ipp32u m_iCurrMBIndex;

VC1EncoderMBInfo* VC1EncoderMBs::GetPevMBInfo(Ipp32s x, Ipp32s y)
{
    Ipp32s row = (y > 0) ? m_iPrevRowIndex : m_iCurrRowIndex;
    return ((m_iCurrMBIndex - x < 0 || row < 0)
        ? 0 : &m_MBInfo[row][m_iCurrMBIndex - x]);
}
```

This code fragment is taken from IPP Samples project\. When comparing an expression result with zero, one should keep in mind that _int_ may be cast to _unsigned int_, and _long_ to _unsigned long_\. In our case, the result of the _m\_iCurrMBIndex_ \- _x_ expression will be of type _unsigned_ _int_, so it is always nonnegative \- PVS\-Studio will warn you about this issue: [V547](https://pvs-studio.com/en/docs/warnings/v547/) Expression 'm\_iCurrMBIndex \- x < 0' is always false\. Unsigned type value is never < 0\.

C\# example:

```cpp
public int Next(int minValue, int maxValue)
{
    long num = maxValue - minValue;
    if (num <= 0x7fffffffL)
    {
        return (((int)(this.Sample() * num)) + minValue);
    }
    return (((int)((long)(this.GetSampleForLargeRange() * num)))
        + minValue);
}
```

This sample is taken from SpaceEngineers project\. In C\#, you should always keep in mind that when adding two variables of type _int_, their type will never be promoted to _long_, unlike the situation when you add a variable of type _int _and a variable of type _uint_\. Therefore, what will be written to the _num _variable is an _int_ value,_ _which always meets the _num_ <\= 0x7fffffffL condition\. PVS\-Studio knows about this issue and generates the message [V3022](https://pvs-studio.com/en/docs/warnings/v3022/) Expression 'num <\= 0x7fffffffL' is always true\.

It's great when you know the standard and know how to avoid errors like those discussed above, but in real life remembering all the intricacies of language is difficult \- and totally impossible in the case of C\+\+\. And here's where static analyzers like [PVS\-Studio](https://pvs-studio.com/en/) may be of help\.

## References

1. [C\+\+ type promotion in arithmetic expressions](https://en.cppreference.com/w/cpp/language/operator_arithmetic#Conversions)\.
1. [C\# type promotion in arithmetic expressions](https://www.microsoft.com/en-us/download/details.aspx?id=55979)\.