Why or why not should I use 'UL' to specify unsigned long?

Question

ulong foo = 0;
ulong bar = 0UL;//this seems redundant and unnecessary. but I see it a lot.

I also see this in referencing the first element of arrays a good amount

blah = arr[0UL];//this seems silly since I don't expect the compiler to magically
                //turn '0' into a signed value

Can someone provide some insight to why I need 'UL' throughout to specify specifically that this is an unsigned long?

Answer 1

Probably just a habit on the part of the developer.

There's no benefit to do this except perhaps to ensure that your unsigned data types are very explicitly unsigned.

Answer 2

You don't normally need it, and any tolerable editor will have enough assistance to keep things straight. However, the places I use it in C# are (and you'll see these in C++):

• Calling a generic method (template in C++), where the parameter types are implied and you want to make sure and call the one with an unsigned long type. This happens reasonably often, including this one recently:
  Tuple<ulong, ulong> = Tuple.Create(someUlongVariable, 0UL);
  where without the UL it returns Tuple<ulong, int> and won't compile.
• Implicit variable declarations using the var keyword in C# or the auto keyword coming to C++. This is less common for me because I only use var to shorten very long declarations, and ulong is the opposite.

Answer 3

void f(unsigned int x)
{
//
}

void f(int x)
{
//
}
...
f(3); // f(int x)
f(3u); // f(unsigned int x)

It is just another tool in C++, if you don't need it don't use it!

Answer 4

Some compiler may emit a warning I suppose.
The author could be doing this to make sure the code has no warnings?

Answer 5

In the examples you provide it isn't needed. But suffixes are often used in expressions to prevent loss of precision. For example:

unsigned long x = 5UL * ...

You may get a different answer if you left off the UL suffix, say if your system had 16-bit ints and 32-bit longs.

Here is another example inspired by Richard Corden's comments:

unsigned long x = 1UL << 17;

Again, you'd get a different answer if you had 16 or 32-bit integers if you left the suffix off.

The same type of problem will apply with 32 vs 64-bit ints and mixing long and long long in expressions.