CODEWITHSUNDEEP
c#primitive-types
sharpener
sharpener

Reputation: 1853

Is the bit width of built-in integral value types fixed?

I'm looking for an unamiguous info whether the bit width of (raw) integral types (like byte, short, int, long, etc.) in C# (and thus the mapping to CLI fixed-width types like Byte, Int16, Int32, Int64, ...) is fixed (forever) or it might change in the future (language revision) and we could face similar situations like in C/C++, where the builtin type is at least N bits wide.

The motivation is: could we safely use C#.int as the integral type using 32 bits for its value, or is it better to just use CLI.Int32 for the cases we want exactly 32 bits?

Upvotes: 2

Views: 167

Answers (1)

Dimitar Tsonev
Dimitar Tsonev

Reputation: 3882

The motivation is: could we safely use C#.int as the integral type using 32 bits for its value, or is it better to just use CLI.Int32 for the cases we want exactly 32 bits?

Technically, they are the same.

int is equal to Int32

Why we can represent the same type with two different names ? The idea is that the primitive types are probably the most commonly used, and so the C# team created aliases for the types in order to write code faster.

Based on the above, the declaration int n is equivalent to Int32 n = new Int32()

Also note that the C# features are only subset of the features of CLI. Which means that in CLI there may be types, which are not implemented in C# and vise versa. For example, in CLI there is no UInt32 (unsigned integer), but in C# it does.

Based on the above, if new type is implemented in CLI or C#, this doesn't mean that it will be implemented in the opposite. Also, I don't believe that someone will change the implementation of the already existing types as this will break compatibility.

Upvotes: 3

Related Questions