Re: Array indexing

"Old Wolf" <oldwolf@xxxxxxxxxxxxxx> wrote in message
Malcolm wrote:

There are lots of problems with size_t. It looks ugly,

Introspection?

No. It is ugly. And that isn't a trival issue. When code looks like line
noise it becomes unreadable, and then it gets hard to maintain, and you get
bugs.
As happened to Perl and C++. size-t is admittedly only a small step in that
direction, but its a step in the wrong direction.
>
it is unsigned,

When was the last time you had a chunk of memory with
a negative size?

When was the last time you had a negative amount of money in your pocket?
However you can have an negative amount in your account. Intermediate
calculations of the sizes of memory objects may give negative results.

it doesn't interface with other languages,

C doesn't interface with other languages.

Yes it does. C frequently has to call non-C code, or be called by it.
Anything that makes that process easier is a good thing.

it is a misnomer when not used to describe a size of memory,

You should use it for describing a size of memory. Would you
also criticise 'char' because it is a misnomer when not used to
refer to a character?

Yes I would. The fact that char and byte are the same thing in C is a major
headache to anyone who has had to use a non-English language. However that
is somethign we are stuck with. size_t is a newcomer which can still, just,
be syuppressed if we are determined enough to squeeze it out of our nice C
code.

it adds another type to the pool

Usually it is an alias for an existing type

It is another type swilling about. The fact that it probaly has the same
number of bits as another type is neither here nor there.
Now Bloggs writes

setpixels(size_t *x, size_t *y, size_t N)

because size_t is the right thing for an index, right?

Muggins writes
int *xvals;
int *yvals;
int N;

Because his pixel co-ordiantes are integers.
Now he calls Blogg's setpixels() routine. Oh dear. The code becomes a mass
of castings and type conversions. It's the two standards problem. We need
one standard way of representign integers in the machine.

and complicates the language.

How would you implement malloc without size_t ?

Standard:
malloc() takes an numerical type as its argument which must be an integer.

Normal application

void *malloc(int N)
{
assert(N >= 0);
}

Because on normal machines there simply isn't enough memory to overflow the
range of a singed integer, so this isn't a problem.

squeezed compiler, maybe on an embedded machine

void *malloc( unsigned long long N)
{
}

weird compiler (why not do this?)

void *malloc(double N)
{
assert(N == floor(N));
}

0.5 out of 6 for you (at best)

Don't be arrogant. Maybe you don't have the intellectual capacity to
appreciate the strength of the point being made.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.


.

Relevant Pages

  • Re: Argument of free() should be const void*
    ... Doesn't malloc return void*? ... Changing the prototype of free to take a const-qualified pointer changes the ... it is quite common to wrap memory allocation calls with ...
    (comp.std.c)
  • Re: sizeof(ptr) = ?
    ... The value returned by malloc() is of type 'void*', ... The memory is typeless until an object has been written ... Since 'void' is defined to be an incomplete ... an lvalue of a complete type, there must be a pointer conversion ...
    (comp.lang.c)
  • Re: Implementing Malloc()
    ... Suppose the user requests 1Mb of memory. ... The huge majority of programmers won't bother to check malloc() failure ... void *calloc{ ...
    (comp.lang.c)
  • Re: Implementing Malloc()
    ... Suppose the user requests 1Mb of memory. ... The huge majority of programmers won't bother to check malloc() ... void *calloc{ ...
    (comp.lang.c)
  • Re: [PATCH RT 00/02] SLOB optimizations
    ... > Linux's memory management is starting to show it's age. ... The slab allocator is indeed complex, messy, and hard to understand. ... +#undef CACHE +}; +EXPORT_SYMBOL; + +struct cache_names { ... +void *kzalloc+{ ...
    (Linux-Kernel)