Why Is Ushort + Ushort Equal to Int

Why is ushort + ushort equal to int?

The simple and correct answer is "because the C# Language Specification says so".

Clearly you are not happy with that answer and want to know "why does it say so". You are looking for "credible and/or official sources", that's going to be a bit difficult. These design decisions were made a long time ago, 13 years is a lot of dog lives in software engineering. They were made by the "old timers" as Eric Lippert calls them, they've moved on to bigger and better things and don't post answers here to provide an official source.

It can be inferred however, at a risk of merely being credible. Any managed compiler, like C#'s, has the constraint that it needs to generate code for the .NET virtual machine. The rules for which are carefully (and quite readably) described in the CLI spec. It is the Ecma-335 spec, you can download it for free from here.

Turn to Partition III, chapter 3.1 and 3.2. They describe the two IL instructions available to perform an addition, add and add.ovf. Click the link to Table 2, "Binary Numeric Operations", it describes what operands are permissible for those IL instructions. Note that there are just a few types listed there. byte and short as well as all unsigned types are missing. Only int, long, IntPtr and floating point (float and double) is allowed. With additional constraints marked by an x, you can't add an int to a long for example. These constraints are not entirely artificial, they are based on things you can do reasonably efficient on available hardware.

Any managed compiler has to deal with this in order to generate valid IL. That isn't difficult, simply convert the ushort to a larger value type that's in the table, a conversion that's always valid. The C# compiler picks int, the next larger type that appears in the table. Or in general, convert any of the operands to the next largest value type so they both have the same type and meet the constraints in the table.

Now there's a new problem however, a problem that drives C# programmers pretty nutty. The result of the addition is of the promoted type. In your case that will be int. So adding two ushort values of, say, 0x9000 and 0x9000 has a perfectly valid int result: 0x12000. Problem is: that's a value that doesn't fit back into an ushort. The value overflowed. But it didn't overflow in the IL calculation, it only overflows when the compiler tries to cram it back into an ushort. 0x12000 is truncated to 0x2000. A bewildering different value that only makes some sense when you count with 2 or 16 fingers, not with 10.

Notable is that the add.ovf instruction doesn't deal with this problem. It is the instruction to use to automatically generate an overflow exception. But it doesn't, the actual calculation on the converted ints didn't overflow.

This is where the real design decision comes into play. The old-timers apparently decided that simply truncating the int result to ushort was a bug factory. It certainly is. They decided that you have to acknowledge that you know that the addition can overflow and that it is okay if it happens. They made it your problem, mostly because they didn't know how to make it theirs and still generate efficient code. You have to cast. Yes, that's maddening, I'm sure you didn't want that problem either.

Quite notable is that the VB.NET designers took a different solution to the problem. They actually made it their problem and didn't pass the buck. You can add two UShorts and assign it to an UShort without a cast. The difference is that the VB.NET compiler actually generates extra IL to check for the overflow condition. That's not cheap code, makes every short addition about 3 times as slow. But otherwise the reason that explains why Microsoft maintains two languages that have otherwise very similar capabilities.

Long story short: you are paying a price because you use a type that's not a very good match with modern cpu architectures. Which in itself is a Really Good Reason to use uint instead of ushort. Getting traction out of ushort is difficult, you'll need a lot of them before the cost of manipulating them out-weighs the memory savings. Not just because of the limited CLI spec, an x86 core takes an extra cpu cycle to load a 16-bit value because of the operand prefix byte in the machine code. Not actually sure if that is still the case today, it used to be back when I still paid attention to counting cycles. A dog year ago.

---

Do note that you can feel better about these ugly and dangerous casts by letting the C# compiler generate the same code that the VB.NET compiler generates. So you get an OverflowException when the cast turned out to be unwise. Use Project > Properties > Build tab > Advanced button > tick the "Check for arithmetic overflow/underflow" checkbox. Just for the Debug build. Why this checkbox isn't turned on automatically by the project template is another very mystifying question btw, a decision that was made too long ago.

Why does ~(ushort)1 returns an int?

ushort lacks bitwise operators, unlike int, uint, long and ulong - as per the docs.

As such, the ushort is promoted to an int before applying the bitwise negation.

using int (32-bit) vs cast to ushort

A byte in C# is unsigned (values 0 to 255). Therefore I would go with ushort as well.

Which one is better?

The one that provides better semantics to future readers. With an ushort, it's immediately clear that only 2 bytes will fit in. If you use an int instead, one might wonder what the other 16 bits are good for.

Also, with int, bit-shift operations may work differently in case the value is negative for whatever reason.

Which one is more efficient?

Why care about efficiency if you have no performance problem?

Why is DateTime.Now.Year an int and not a ushort

Thus, a ushort (System.UInt16) is more than adequate to store the value and takes up half the space.

Where do you think that "space" is being wasted? DateTime doesn't store each component in a separate field anyway. If you're storing the year somewhere, feel free to cast it to a ushort - and cast Month to a byte, etc.

Note that ushort isn't CLS-compliant, which is probably the reason for it. There are a lot of properties which would make sense to be unsigned, such as string.Length etc... but the framework tries to be CLS-compliant where it can.

ushort Operations Throwing Int Cast Errors

Is there a use case for smaller types today?

Yes, there is a case for it. Memory is still limited, especially when working with "big data", so saving half your memory by using a short instead of an int can be very valuable, especially if you need to process or store billions of items of data.

Edit: How do I do the cast on these to ushort?

You can just use a cast of the form (ushort):

ushort digitSum = (ushort)(firstDigit + secondDigit + thirdDigit + fourthDigit);

ushort equivalent

The closest equivalent in terms of size is char, since Java doesn't have unsigned types, but it's overloaded in Java to provide additional semantics related to individual characters. In general, just pick the next largest integral type (int, in this case). (You're not the only one who wants it, though.)

Why does ((object)(int)1).Equals(((object)(ushort)1)) yield false?

Int32.Equals(object) returns true only if the other object is also an instance of Int32:

true if obj is an instance of Int32 and equals the value of this
instance; otherwise, false.

In code (ILSpy, .NET 4):

public override bool Equals(object obj)
{
    return obj is int && this == (int)obj;
}

Since obj is int returns false you get a false.

Edit: ragarding to your edit(Hashtable with "similar" keys): if you don't want to allow duplicate objects use a Dictionary<int, string> instead(preferred) or add only ints to the HashTable.

Why is unsigned short (multiply) unsigned short converted to signed int?

You may want to read about implicit conversions, especially the section about numeric promotions where it says

Prvalues of small integral types (such as char) may be converted to prvalues of larger integral types (such as int). In particular, arithmetic operators do not accept types smaller than int as arguments

What the above says is that if you use something smaller than int (like unsigned short) in an expression that involves arithmetic operators (which of course includes multiplication) then the values will be promoted to int.

---

Related Topics