Using unsigned int troubles

I'm trying to build simple open addressing via linear probing hash tables where I store phone numbers for keys of string names. I am using a tested and tried string hash function called FNV. I'm using g++ compiler that came with CodeBlocks IDE and when I compile, it complains w/ this message:warning: this decimal constant is unsigned only in ISO C90

Code:

---

unsigned fnv_hash ( string key, int len )
{
  unsigned h = 2166136261;
  int i;
 
  for ( i = 0; i < len; i++ )
    h = ( h * 16777619 ) ^ key[i];
 
  return h;
}

int main()
{
  int phonebook_1[10] = {0,0,0,0,0,0,0,0,0,0};//always initialize size since specific compilers say its ok so don't get comfy w/ bad practices
   
    int size_1 = 10;
   
    string name_1 = "Cooke";

  int bucket = fnv_hash ( name_1, size_1 );
 
  phonebook_1[bucket] = 1234567;

  return 0;
}

---

Here is the src: Eternally Confuzzled - The Art of Hashing

BTW: when I type in g++ -v, it shows the gcc version:
gcc version 4.4.1 (TDM-2 mingw32)

To get rid of the warning change this line.

Code:

---

unsigned h = 2166136261;

---

To

Code:

---

unsigned h = 2166136261U;

---

An integer constant ending with L mean long int
UL means Unsigned Long Int
U seems to mean Unsigned Int. (I never used just an U, before)

ULL can mean Unsigned Long Long; but it might not be supported on all Compilers and I am not sure if it is standard.

Tim S.

Quote:

---

Originally Posted by stahta01

ULL can mean Unsigned Long Long; but it might not be supported on all Compilers and I am not sure if it is standard.

---

It is standard, but unlikely to be supported by all compilers at this time.

Of course, don't forget LL, which is also standard but unlikely to be supported by all compilers at this time. It stands for "laserlight". I mean "long long".

This might sound trivial, but if a value is unsigned, does that mean it can represent 2^32 distinct binary values which is: 4,294,967,296 so why does the compiler complain. The suffix of 'U' to add on works btw, thanks for that, and does compiler complain b/c 2166136261 in binary exceeds 32 bits?

The reason suffixes exist is so that numerical expressions can be the right type. This is just a rationalization, but there is no way to tell a big signed integer expression from an unsigned one without the suffix. It's also a good heuristic that you can use to point out mistakes: If the type of the expression will be signed, huge numbers will overflow the type, and the behavior is implementation defined for signed numbers. Along with other logical errors.

The compiler just wants you to be careful and it's a good thing.

Quote:

---

Originally Posted by monkey_c_monkey

This might sound trivial, but if a value is unsigned, does that mean it can represent 2^32 distinct binary values which is: 4,294,967,296 so why does the compiler complain. The suffix of 'U' to add on works btw, thanks for that, and does compiler complain b/c 2166136261 in binary exceeds 32 bits?

---

You need to understand that a number can either be signed or unsigned. Regardless of choice, a 32-bit variable can hold 2^32 distinct values. That's just basic algebra.
The problem is that when we want signed numbers, we must reserve one bit for the sign, essentially. So the "range" of the variable will be "halved."
So, when you type 2166136261, which is 811C 9DC5 in hex, the compiler sees that it cannot be represented by 31 bits (the largest number would be 8000 0000 - 1).
The compiler does not know whether this is a 63-bit number or an unsigned 32-bit number. You have to tell the compiler whether you meant an unsigned 32-bit number (uses 32 bits to store the number) or a signed 64-bit number (uses 63 bits to store the number, plus 1 for the sign).

Quote:

---

Originally Posted by Elysia

Regardless of choice, a 32-bit variable can hold 2^32 distinct values. That's just basic algebra.

---

What you say is true for most 32 bit integral types (signed or unsigned) but is not true for all 32-bit types.

The algebra actually says that a 32-bit variable can hold at most 2^32 distinct values. Consider the fact that some 32 bit floating point representations (a typical float type in cases where sizeof(float) is 4) reserve some bits to represent NaN (not a number), infinities, and some error conditions. Struct types that have a 32 bit representation (for example, a struct that contains small number of char or short variables) may have padding.

Admittedly, I've yet to see a 32-bit integral type, whether signed or unsigned, that does not use all 32 bits to represent values.

Quote:

---

Originally Posted by Elysia

The problem is that when we want signed numbers, we must reserve one bit for the sign, essentially. So the "range" of the variable will be "halved."

---

That depends on what you mean by "range". If you mean that std::numeric_limits<int>::max() is approximately std::numeric_limits<unsigned>::max()/2 then you are correct.

However, "range" usually refers to something representative of an interval from (in this context) a minimum value to a maximum value of a type. For example, the range of a type might be represented as the difference between maximum and minimum value. Mathematically, the range of a 32-bit signed type will be equal to the range of a 32-bit unsigned type (assuming no reserved bits, etc in the representations).

What I mean, is simply that a number is that 32 bits long can hold 2^32 different combinations. Now, computers interpret these different combinations differently, sometimes even treating two different combinations as the same thing (+/- 0).

Find me any integer that has an ambiguous bit pattern. I don't think it can be done.

Zero is not an example. All representations of negative numbers reserve a pattern for zero; in two's complement it is all bits 0. In fact if you start with 0U and do
~0U + 1 (the normal way of doing it in two's complement)
you get all bits 0 again because the sum wraps around.

Now that you say it, it might be difficult in two's complement, but not one's complement.
Well, let's just say that it isn't a requirement that all unique combinations of the binary representation must map to a unique number representation.

I guess that's what I wanted you to say. :)
(-0) should not even be a number, but in ones' complement it is, and it certainly isn't the same number.

Quote:

---

but there is no way to tell a big signed integer expression from an unsigned one without the suffix.

---

quote from whiteflags.

But if I use unsigned h, isn't that enough of a clue to tell compiler I am working w/ unsigned, so I'm still not getting the purpose of including suffix U.

Yes, and no.
It tells the compiler that the type of your variable is unsigned int, but it tells the compiler nothing about the type of your number. Some compilers, however, are smart enough to figure it out by themselves.
Nevertheless, if you don't use proper suffixes, you may find that the code does not do what you want.

Quote:

---

But if I use unsigned h, isn't that enough of a clue to tell compiler I am working w/ unsigned, so I'm still not getting the purpose of including suffix U.

---

No it really isn't. Declaring unsigned h means that the resulting type of the variable will be unsigned. The compiler is free to do an implicit conversion from signed to unsigned. If you want to avoid that, use suffixes. You should want to avoid implicit conversions anyway.

Ah yes, prime example:
float f = 1 / 2;
What is the result?