Keith said:
That's well argued, but I disagree.
I think we already had this discussion before.
We use what we have. We have a type size_t that's designed to count
sizes (in bytes) of objects. We don't have a similar type that's
designed to count the number of elements in an array of struct foobar.
If we had such a type, I'd advocate using it (for example, if
declaring "struct foobar" implicitly created an unsigned int typedef
called, say, "struct_foobar_count").
That only appears so. Whenever some type (say 'struct foobar') is given
some application-specific meaning (say, describe an employee in a
company) and represent a 'countable' object (say, we normally have many
employees in a company) there exists a need to choose a type that will
be used to represent these 'counts', these application-specific
quantities. Note, that we are not talking about any "arrays" yet, but
the need to have the type that represents the 'quantity' already exists.
Now, once we start using arrays, that 'quantity' type immediately
springs to mind as the best choice for index type. Note, that we indeed
"use what we have", as you said in your message. I just want to say that
by the time we get to arrays, we will already "have" the index type, and
it is not 'size_t'. 'size_t' is a bad choice to represent generic
'quantities' for obvious reasons (it might simply not have the range,
think of segmented 16-bit platform with 16-bit 'size_t').
Once again, 'quantities' predate 'arrays'. By the time we get to
'arrays' (or any other containers, for that matter) we should have
already made all the necessary choices about 'quantity' types.
Using size_t to count objects isn't ideal, but it's what we have.
Since objects (other than bit fields, which we generally wouldn't be
interested in counting) are at least one byte each, we know that
size_t has *at least* enough range for the purpose.
In general case 'size_t' is not applicable for counting objects at all.
In general case it's range is not sufficient (16-bit platform again).
Yes, 'size_t' is applicable for counting _array_ _elements_, but that's
nothing more than a language-specific parasitic relationship between the
byte-size of array and the number of elements in it. Letting this
parasitic relationship to seep into the design of application-specific
code is not the right thing to do.
I don't believe
any other type would be any better, and size_t isn't sufficiently bad
that I'd recommend avoiding it.
If the language had a type to be used generically for counting
objects, surely it would be just an alias for size_t, since the
objects could be bytes in an array. I'm not greatly distressed by the
fact that it's called "size_t" rather than "object_count_t".
Once again, on a traditional 16-bit segmented platform with 16-bit
'size_t' the difference between the concept of 'object size' and 'object
count' is especially obvious. As is the inappropriateness of choosing
'size_t' as generic object count type.