Numeric Data Types

Imagine a small program that keeps a running count of the items it processes. At the start the count is zero, and every time an item is handled the count goes up by one. Most of the time this looks like a simple task. The question that matters is not how to add one, but whether the place where the count is stored can hold the largest value the count will ever reach.

Every number a program stores lives in a numeric type, and each numeric type has properties of its own. Those properties decide what values the type can hold and how it behaves. A type that works well in one part of a program may be unsuitable in another, so picking a numeric type without looking at its properties is a guess. Before reading on, try to name what you would need to know about a number type before trusting it with a value that could grow very large.

The key idea is that these properties can be checked. You do not have to rely on memory or on the assumption that a type is large enough. Once you know what the properties are, checking them turns a guess into a decision. A type is adequate when its properties cover the requirement of the task it has to perform. Adequacy is therefore always relative to a task: the same type can be adequate for one job and inadequate for another.

The properties of numeric types are accessible through numeric_limits. This is the mechanism for reading a type's properties directly. Rather than memorizing the limits of each type or assuming them, you ask numeric_limits for the information about the type you are using. The information it gives you is the raw material for the adequacy decision.

The diagram shows one lookup mechanism branching into several properties. The same mechanism serves every numeric type, so the question you ask does not change when you move from one type to another. What changes is the answer: each type reports its own properties. The values reported by numeric_limits are the ones you compare against your task's requirements, not values you should assume in advance.

Go back to the running count. Suppose the count has reached the largest value its type can hold. If the next increment produces a result above that maximum, the type cannot store that result as a correct value. The count stored in the variable no longer matches the true number of items processed. This is the situation the source warns about when it says a type that is not checked can go wrong quietly.

Read the diagram from left to right. The count sits at the type's maximum, the increment asks for a value one step beyond it, and the stored result is no longer a faithful record of the count. The important detail is that nothing in this sequence necessarily announces the error. The program keeps running with a wrong number, which is why the adequacy check has to happen before the program is trusted with real data.

The reason to check numeric type properties is that a type with a range or precision too small for the task's data produces a chain of consequences. First, the stored value stops matching the real value the program is supposed to represent. Second, every later computation that uses that value inherits the error. Third, the output of the program can look plausible while being wrong, so the failure may only be noticed much later, if at all.

The adequacy check follows a clear order. You begin by identifying what the task requires, then query the limits of the candidate type, then compare the two, and finally decide. The flowchart below lays out this sequence. If the type covers the requirement, you use it; if it does not, you choose another type and check again.