Should I use the ushort, uint and ulong types whenever the number is equal to or greater than 0?

Question

Is it good practice or is there something from Microsoft recommending the use of ushort, uint and ulong whenever I am sure that the value will be equal to or greater than 0?

I can gain some advantage using them instead of the traditional short, int and long? (It is not possible to receive a number less than 0).

An example would be a method that would generate a random user name, and it would be possible to provide the maximum length:

public static string GenerateUsername(int maxLength) {...}

In this case I always know that the maximum length will not be less than 0, so I should use uint instead of int?

My doubt arose mainly because I believe I have never seen the use of these guys in frameworks, libraries, etc....

Answer 1

No, these types exist primarily for low-level communication with the operating system or other services that require these types.

All framework, except when doing the above, it is all designed to work with the flagged types.

Unmarked types may not actually have a negative number stored in it, but nothing guarantees that a negative number is assigned to it, which will cause a data loss and will not have the expected result (in context unchecked, C# protects misuse by default). Don’t think of these types as positive natural numbers, they’re not that.

A user name with 4 billion characters? I hope not. A byte is sufficient, and this type is flagged because almost always when only want 1 byte of capacity, wants it whole. Some people complain about this language decision.

If it were another example that makes sense int would allow 2 billion size. Almost always this is sufficient, so much so that the collections of . NET use a int as length (by default, has how to use the long). If you need more than 2 billion you probably need a lot more than 4 billion, and then long is more suitable. It is very rare to need more than 2 billion and less than 4. If this is necessary the long is still the best solution. 4 byte loss is not usually a problem. If it is a problem, then the uint can be used, but very carefully and prepare to have other problems communicating with the rest of the application that does not expect this type.

Just because the domain shown does not allow value less than 0 is no reason to use uint.

If you use the uint alone does not have so much problem, the broth sprains when it begins to mix it with the marked type, the rules of promotion start to get complicated.

In C it is much more used because it is a language that does more low-level things. Although the use ends up being worth even more in fixed size types since the standard of C is to have types with size dependent on the platform. In C# the use is extremely rare, and almost all the few cases is because of interoperability.

It is not the case of C#, today, but has languages that make a "smart" use in certain situations of negative number where expected only positive.

The rules of one language are not the same of another, which complicates a little more.

As amazing as it may seem to deal with unsigned is usually slower on major processor architectures, as well as short may be slower than int.

Although today saving memory is more important, people talk nonsense when they think that memory is no problem nowadays. The typical processor today has only 4, 6 or 8MB, in mobile neither, and is a slow memory, the fast has 32 or 64KB. RAM is an aid to store large volumes of data that do not fit in the processor, to make something be fast the data must be in the processor, this gives much more performance than saving some pure processing cycles.

But don’t try to do economy without testing very well in various scenarios, and only if you need a lot, and know all the details that can change. I mean, it’s the kind of optimization that’s not for the nozzle of almost any programmer.

Before you see the example in Fiddle note down the results you expect this code to print:

var x = 0u;
System.Console.WriteLine(x - 1);

Behold working in the ideone. And in the .NET Fiddle. Also put on the Github for future reference.

Did you get all the results right? Are you sure you’ll always get them all right? Do you know all the rules? Don’t I know :)

Try passing a int where one expects a uint. It has a solution, but it’s ideal or it looks like you’ve been rooting for a wrong decision before?

These guys are not even part of CLS.

If you want a type that guarantees only positives, write one that does this and interacts well with all other numerical types, including those that don’t seem to be as numerical as well, such as DateTime.

That’s why I always say that programming is more complicated than it seems, and it’s a good thing that it’s like this, it wouldn’t be fun if it wasn’t :) Luckily some people try to learn all the details. Unfortunately, most people think that just learning the superficial is enough.

It’s great to have the type in the language for cases where it’s needed, but it’s not to use without reason.