Signed intergers are used for mathmatical equations etc, but cos they go into the minus their largest positive number is quite small.
Well, "small" is relative - with a signed 32 bit integer the range is roughly -2^31 to 2^31, i.e. more or less -2,147,483,648 to 2,147,483,648 (I am most likely one or two off, can't be bothered). So yes, small is relative; 2 *billion* in either direction really isn't that small for vnums!
I don't think you really need unsigned integers for vnums, unless of course you're planning on having more than 2 billion rooms (uh-huh :P). There seems to be this myth about how integers are "small" but mostly that's because people don't understand how it all works.
Then what Ksilyan is saying is that with Muds you need high Vnums and so need unsigned intergers, but then when you set an invalid vnum you would be using up a perfectly good vnum and so he made the vnum a C++ structure to get around this.
No, that's not what I said... You don't need vnums *that* high. If you're using 16-bit shorts, then yes, you do; but if you're actually using integers, leaving the sign bit is fine and in fact very convenient for representing invalid vnums (-1).
The C++ structure I made was out of convenience, a somewhat "cleaner" version of the vnum. My vnums are two-piece, "unsigned short.unsigned short", with a third field (bool) to indicate "valid" or not. The idea is to make the notion of valid independent of the value, and to make programming with them easier and more convenient. Also, having a struct like this also helps a great deal in ensuring type safety (e.g. you can only assign vnums to vnums, you can only compare vnums, etc.), which C++ is much better at than C.
Also just to make sure data types are used to store your variables, and they tell your computer what to store the variables as. Right?
I guess that's one way of putting it. I would prefer saying that they tell the program what is contained in the variable, e.g. a c-style struct has a grouping of fields, a class has variables and methods, etc.