Malcolm McLean wrote, On 11/11/07 08:52:
Time of writing != compile time.
Not is it requirements analysis time, of which more later.
Let's say we want to calculate a standard deviation. The prototype is
double stdev(double *x, N);
what type should N be? If you don't know how big the maximum array is
going to be, which you don't for this function - except that it fits in
memory - it must be a size_t.
However, you have either failed to do requirements analysis (in which
case your project deserves to fail) or you know or have decided on some
limits. If you really have no limits then it is impossibly because
computers are finite and if you don't know them then you don't know if
it is possible on a 32 bit computer, 64 bit computer or if you need a
supercomputer.
Thus we must write
size_t i;
for(i=0;i<N;i++)
{
}
Of course that is misleading, because i is not in any shape or form a
size type.
If you find it misleading you are easily mislead.
So? That means it is something that has to be able to span the size of
an object. You can always to
typedef index_t size_t;
if you want.
The implications of introducing
size_t simply weren't thought through.
They were thought through a lot more carefully that you seem to have
thought through your ideas.
You find that functions like stdev() are by no means uncommon. Very
frequently you will not hard code the size of an array, until maybe in
the very top layer of code.
See previous comments about requirements analysis. Also see comments in
previous posts about the fact that using an int is also imposing limits
and using a typedef if there might be reason for the type being changed.
The worse problem is that, frequently, you don't know the exact size of
an array but you know that it will be small.
See, you do know something about the size before you start writing code.
Now you just have to use that information when you design your program.
For instance the number of
children in a class. Should that be a size_t or not? If we sort the
class by grade, qsort() takes two size_ts. However people will naturally
gib at using a size_t when an int, realistically, is going to be enough.
So? If you choose to use int for efficiency then it will be converted to
size_t, and if your value is within range (which you have just said it
will be) the conversion will do what you expect.
So you get inconsistency.
IF you use int because you know from your requirements analysis it is
sufficient and you want the efficiency then you use it consistently
within your code and it gets converted when passed to a library function
that expects a size_t. If you use size_t consistently it is all the same
time. Either way there is no problem. Also no problem if you use your
own typedef (and #defines) so you can change the type easily later if
there is a risk of needing to change it later. That is the wonderful
thing about most programming languages (including ones I don't like),
they provide mechanisms to solve problems if you bother to learn and
understand them.
Most integers are ultimately used as index variables. Not every integer,
of course, for instance if you dealing with amounts of money you may
choose to represent the sums by integers. But every time you add up a
list of amounts of moeny, you will have one index integer to iterate
through the array and another to count it. Programs don't spend their
time doing calculations, but on moving data from one place to another.
All unsupported rubbish which has been pointed out to you many times by
people who have actually spent a lot of time working in the SW industry.
Something like 20% of all mainframe cycles are used in sorting, for
instance.
Another statistic which I suspect you have pulled out of thin air.
Even if an integer is a type field, typically that is used as an array
index. For instance if we have an emum {MR, MRS, MISS, MS, DR, REV,
PROF, LORD} we will probably have an array of strings we index into to
help us construct letters.
I don't for most of my enums, and for the ones I do that is an
occasional use not the main use of the variables.
It varies. Some people will use size_t if it is a generic library to
ensure it can cope with any size of object, some will use int because
they are more concerned with efficiency (correctly or not) and some will
select a type without thinking it through. Just like any other design
decision really.
That's the problem. Really virtually every integer in the program should
be a size_t, because they will almost all end up being used to derive
index calculations.
Malcolm is talking rubbish again.
But that is unlikely to be accepted, partly because
of the unsignedness
People have explained why this makes sense and is perfectly acceptable
to people other than you.
and efficiency considerations,
Ah, so a size_t large enough to access any byte of any object introduces
unacceptable efficiency problems but *your* desire for an equally large
int type does not?
but mainly because to
type "size_t i;" is so counter-intutitive.
Only to you. Most people seem not to have a problem with it.
That's why I think think size_t will ultimately have to go, and the
introduction of 64-bit types on the desktop will be the catalyst for
this, because it will no longer be true that int can index an arbitrary
array.
You don't see the contradiction of claiming that a large enough int is
not a problem but an equal size size_t introduces efficiency problems?
To the OP, Malcolm has been spouting this rubbish for a while now, but
in all the years since the ANSI standard was introduced in 1989, despite
Malcolm's dire predictions of what size_t will do to the language, it
has not killed C. Including all the years with a 16 bit int type and
objects too large to be address by it.
