Should I always use size_t when indexing arrays?

Question

Do I need to use size_t always when indexing an array even if the array is not big enough to exceed the size of an int?

It's not a question about when I should use size_t. I just want to know if, for example, a program having 2GB of available memory (all of these fields can be indexed by an int32) but with this memory being (virtual memory) assigned to the "fields" 14GB - 16GB of the computer's RAM.

Would it always fail when indexing the memory if I used an int32 instead of a size_t (or an unsigned long int) in this case?

Maybe the question is more about virtual memory than about pointers.

Answer 1

size_t is an unsigned integer that is capable of holding the size of the largest object you can allocate. It is useful for indexing because this means it can index into the largest array you can allocate.

This does not mean it is required or even necessarily recommended for indexing. You can use any integer type that is large enough to index the array. int_fast32_t might be faster, uint_least16_t might be smaller in a structure, and so on. Know your data, and you can make a good choice.

One consideration you should make is that on some platforms, using a signed index might require an extra sign extension instruction. As an example, here is x86-64:

// ; zero-extending idx (in edx) is "free" by simply using rdx.
// movzx eax, BYTE PTR [rcx+rdx]
// ret
char get_index(char *ptr, unsigned idx)
{
   return ptr[idx];
}

// ; sign extending idx from 32 bits to 64 bits with movsx here.
// movsx rdx, edx     
// movzx eax, BYTE PTR [rcx+rdx]
// ret
char get_index(char *ptr, int idx)
{
   return ptr[idx];
}

Virtual memory is outside the scope of C or C++. From their point of view, you simply index into memory and it's up to your platform to make it work. In practice your app only uses virtual addresses; your CPU/OS is translating the virtual address to a physical address behind the scenes. It is not something you need to worry about.