If you've dug into the .NET documentation much, you've probably seen
the framework has unsigned versions of the integral types we use all the
time, and C# considers them built-in types with language keywords to easily use them--
I'm adding a new property to a data object, a count which will never exceed 1000, so I figured
I was surprised to learn these unsigned types are not CLS-compliant; the docs even recommend not using them if you can avoid it. That plus consistency with the .NET Framework outweighs the benefit of the runtime restricting negative values from getting assigned.
Furthermore, even using a
ushort
, uint
, and ulong
.
If you haven't, you may be unfamiliar with them--in 14 years of C#
development, I could probably count on a hand or two the number of times
I've seen them in production code.I'm adding a new property to a data object, a count which will never exceed 1000, so I figured
ushort
was a fitting choice, since it requires less memory & ensures a
negative value will never be set. But I took the opportunity to research
a bit why we don't see those more often, especially in .NET Framework
types, like its Count properties.I was surprised to learn these unsigned types are not CLS-compliant; the docs even recommend not using them if you can avoid it. That plus consistency with the .NET Framework outweighs the benefit of the runtime restricting negative values from getting assigned.
Furthermore, even using a
short
might be overkill on modern processors designed for 32-bit pointers, arithmetic, etc. If short
s get promoted to int
s
implicitly, it makes sense to use ints explicitly for standalone
properties like this; trying to save a few bytes of storage could
backfire if it gets allocated later anyway.
No comments:
Post a Comment