size t

The Problem with Other Types

Common integer types like int or unsigned int have fixed sizes depending on the platform:

• int is usually 32 bits on modern systems, meaning it can store values from -2,147,483,648 to 2,147,483,647.
• unsigned int is also usually 32 bits, allowing values from 0 to 4,294,967,295.

While these ranges are sufficient for most applications, they are not theoretically large enough to represent the size of the largest possible object or array on modern 64-bit systems. For example, a large array with more than the maximum value of unsigned int would make the program have undefined behavior.

This is the reason why you'll see for loops that use size_t rather than int or unsigned int, as .size() of a vector returns a size_t and thus the value could be larger than the largest int or unsigned int causing the variable i to overflow during loop iterations depending on the platform.

    
size_t count = ...; // a value larger than an int
std::vector<int> vec(count); 
// bad: i will overflow on a platform where vec.size() > INT_MAX 
for (int i = 0; i < vec.size(); ++i) { 
    vec[i] = 42; 
}
                      
// good: our index will never overflow
for (size_t i = 0; i < vec.size(); ++i) { 
    vec[i] = 42; 
}
    

The Role of size_t

size_t is guaranteed to be large enough to represent the size of any object or array in memory. On 64-bit systems, it is typically 64 bits.

Using size_t ensures that:

• Array indices can address all elements in a container safely.
• Values returned by sizeof can represent the size of the largest possible objects.
• Unsigned arithmetic is used, avoiding negative sizes or indices.

Conclusion

In summary, size_t exists because other types like int or unsigned int are too small to represent the theoretical maximum object size on some systems. Using these smaller types for sizes or indices could technically fail if objects were large enough, so size_t provides a safe, portable, and standard solution for all memory-related size calculations.