Is integer used too much as a data type?

Question

Do most application developers use signed integers in places where they really mean to use unsigned integers? I do it all the time, so do my co-workers. I haven't seen a lot of other extensive codebases (other than the Delphi VCL) and examples on the internet usually use integer. Whereas the VCL developers use their own data types (which would be the most non-lazy way to go about declaring variables).

Something seems a little dreadful about code like this

TStuffRec = record
   recordID : Integer;
   thingID : Integer;
   otherThingID : Integer;
end;

when it could be written as

TStuffRec = record
   recordID : Cardinal;
   thingID : Cardinal;
   otherThingID : Cardinal;
end;

Functionally, these records almost always work the same (and hopefully will continue to work the same even in 64-bit Delphi). But very large numbers will have conversion issues.

But there are drawbacks to using unsigned ints too. Mainly stemming from how annoying it is to mix the two.

The real question is, is this a thing that actually gets thought about or included in best practices? Is it usually just up to the developer?

Answer 1

One reason why I don't use unsigned integer types all that much in Delphi is that they can create problems when mixed with signed integers. Here's one that bit me once:

for i := 0 to List.Count - 1 do
  //do something here

I had i declared as an unsigned integer, (after all, it's an index into a list that starts at 0, it never has to be negative, right?), but when List.Count was 0, it would not short-circuit the loop as expected because 0 - 1 evaluates to a really high positive number. Oops!

Between the potential safety problems inherent in mixing signed and unsigned integers, and the range issues, (if you're going to need positive numbers larger than high(signed whatever), it's quite likely that you'll also end up needing positive numbers larger than high(unsigned whatever) too, so moving up to the next larger size instead of switching from signed to unsigned of the same size is usually the correct action,) I really haven't found too many uses for unsigned integers when representing most data.

Answer 2

To be honest I tend to use Integers by habit. I got used to fact that they offer ranges big enough for most situations and allow negative values (such as -1). Indeed, a lot of times using bytes/word/shortint would be more appropriate. Now thinking about it I can focus on these spots:

• Perspective. Tilemap size is limited to 192x192 tiles, so I could use byte for addressing tiles and loops. But if map size to be increased I will have to go through every use and replace it with e.g. word. When I need to allow off-map objects I would have to go again to change to smallint.

• Loops. It is often I write a loop "from i:=0 to Count-1", what happens if "i" is byte and Count=0 is that loop runs from 0 to 255. Not that I would want it.

• Uniforming. It's easier to remember and to apply "var i:integer;" than to stop in each case and think "Hm.. here we are dealing with 0..120 range.. byte.. no, wait, we might need -1 for uninitialized.. shortint.. wait.. what if 128 is not enough.. Arrgh!" or "Why is it smallint in this place, not a shortint?"

• Combining. When I need to combine two or more classes together they might be using different data types for their purposes, using broader types allows to skip unnecessary conversions.

• -1. Even when values are on 0..n-1 range I often need to set "no value/unknown/uninitialized/empty" value, which is by common practice -1.

Using Integers allows to skip all these issues, forget about low-level optimization where it is not needed, go higher level and focus on more real problems.

P.S. When do I use other types?

• Counters, they are never negative and are read-only outside of their class.
• Performance/Memory reasons, force to use shorter data types in certain places.

Answer 3

The best practice is to use a data type that fits the needs for the data being used (expected data).

C# examples: If I only needed to support 0 to 255, I would use a byte.

If I needed to support 1,000,000 negative and positive, then int.

Bigger than 4.2 billion, then use a long.

By choosing the correct type, the program will use the optimal amount of memory as well as different types use different amounts of memory.

Here is a C# int reference from MSDN.

int 
 -2,147,483,648 to 2,147,483,647
 Signed 32-bit integer

uint 
 0 to 4,294,967,295
 Unsigned 32-bit integer

long 
 -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
 Signed 64-bit integer

ulong 
 0 to 18,446,744,073,709,551,615
 Unsigned 64-bit integer

Answer 4

Unsigned integer types should only be used to represent cardinal numbers in languages where they represent cardinal numbers. Because of the way the computers that ran C happened to work, unsigned integer types behaved as members of mod-2^n algebraic rings (meaning calculations that overflowed would "wrap" predictably), and the language specifies that in many cases such types are required to behave as abstract algebraic rings even when such behavior would be inconsistent with the behavior of cardinal numbers or mathematical integers.

If a platform fully supported separate types for cardinal numbers and algebraic rings, then I would suggest that cardinal numbers should be processed using cardinal-number types (and things that need to wrap using the ring types). Not only could such types store numbers twice the size of signed types, but a method receiving a parameter of such a type wouldn't have to check whether it was negative.

Given the relative lack of cardinal-number types, however, it's generally best to simply use integers to represent both mathematical integers and cardinal numbers.