Re: Using size_t clearly (appropriately?)



Andrey Tarasevich <andreytarasevich@xxxxxxxxxxx> writes:
Mark Odell wrote:
I've always declared variables used as indexes into arrays to be of
type 'size_t'. I have had it brought to my attention, recently, that
size_t is used to indicate "a count of bytes" and that using it
otherwise is confusing.

It might me. Not as much "confusing", as conceptually
incorrect. 'size_t' type is intended to be used to represent a
concept of 'size of an object'. Number of elements in the array is
described by a completely different concept of 'number of elements
in a container'. Note, that is case of generic container these two
concepts are completely unrelated. In the particular case of an
_array_ there's certain "parasitic" relationship between the two:
the latter cannot be greater than the former. This is often used as
a justification for using 'size_t' to represent array indices. This
is a false reasoning. In general case, once again, using 'size_t'
for this purpose is a conceptual error.

That's well argued, but I disagree.

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").

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. 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".

--
Keith Thompson (The_Other_Keith) kst-u@xxxxxxx <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
.



Relevant Pages

  • Re: The inaugural VB6 vs dot net test
    ... If you do Command1 first, ... Command2 operates on an array that already has been ... way than counting up loops. ...
    (microsoft.public.vb.general.discussion)
  • Re: sort algorithm
    ... To output the sorted list, just dump the counts array. ... distribution counting into bins took: ...
    (comp.programming)
  • Re: Using size_t clearly (appropriately?)
    ... a justification for using 'size_t' to represent array indices. ... designed to count the number of elements in an array of struct foobar. ... 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). ...
    (comp.lang.c)
  • Re: 0 based collections
    ... Visual Basic has in my opinion taken the right approach that counting start ... Zero other than Null. ... However, almost every collection and array in VBNet starts at Zero, with the ...
    (microsoft.public.dotnet.languages.vb)
  • Re: sxhash and object identity
    ... > actually return a new array rather than succeeding at expanding the ... > I'm using (sxhash array) for such a purpose, ... isn't the same as object identity given the possibility for objects to ...
    (comp.lang.lisp)