What is the purpose of arrays in C, when pointers could have done the job?

Question

Arrays and pointers are not the same thing in C, although they are related and can be used similarly. So far we all agree.

However, I don't see why arrays were included in C, when pointers could have done their job perfectly.

I am not saying to remove the array notation (e.g, a[5] or int a[4] = {0,1,2,3};), which is quite useful and convenient. But you could have that same notation working on top of pointers (as is the case), as a cosmetic measure. So the array notation is not a reason to have arrays, just the notation!

The only difference I see is that arrays are constant pointers, and the size of memory they point to can't be changed. But this can be achieved with pointers as well, exactly by making them constant (the memory wouldn't be of fixed size, but I am not sure if this is an issue).

So why not have only pointers and let the programmer decide how the pointer should behave (i.e., constant, not constant, fixed size, variable size, etc)?

Answer 1

Arrays are contiguous memory created on the stack. You can't guarantee contiguous stack memory without this syntactic sugar, and even if you could, you'd have to allocate a separate pointer in order to be able to do the pointer arithmetic (unless you wanted to do *(&foo + x), which I'm not sure but it might violate l-value semantics, but is at least quite awkward, and would scream out for some kind of syntactic sugar). Design-wise, it also is a form of encapsulation, since you can refer to the collection with a single identifier (which would otherwise require a separate pointer). And even if you could allocate them contiguously and allocated a separate pointer to reference them, you'd have either int fooForSomething, fooForSomethingElse... which forces a fair amount of creativity as your collection grows, so you might think to simplify with int foo1, foo2 ..., which looks just like an array but is harder to maintain.

Answer 2

Array notation is convenient, easier to read, and less prone to errors. It provides a formalism over pointers. It might be syntactic sugar, but we all need a little sweetness once in awhile, don't we?

As with all abstractions, you give up a little flexibility for the convenience that the abstraction provides.

Answer 3

I am surprised that nobody has commented anything about multidimensional arrays yet.

If you have a matrix made of "nested pointers" (say int **p) what you have in each "row" (outer dimension) is a pointer that points to the first element in that row, so accessing a value requires two memory access. Plus, the memory it requires is sizeof(*int)*n + n*m*sizeof(int).

In the bidimensional array scenario int p[n][m], accessing an element requires just one memory access, because the address of the row is calculated rather than looked up; and the memory required is just n*m*sizeof(int).

Another place where an array cannot be replaced by a pointer is inside structures.

struct s {
    int[2];
    float;
}

is definitively not the same as

struct s {
   *int;
   float;
}

the size of the array is important there, and pointers do not have that information.

So yes, unidimensional arrays and single pointers are mostly interchangeable, but their similarities end there.

Answer 4

Why would I want to not be able to use arrays for value types?

int a[4] = {0,1,2,3};

Answer 5

How would you handle platforms, like the 8031 without external memory, that don't support malloc or alloca? Perhaps you're forgetting that C isn't just for big iron but is also for elevator controllers and toasters.

Answer 6

In C, array notation within expressions is always simply pointer arithmetic. All uses of an array identifier in an expression are immediately converted from "array of T" to "pointer to T" and the value is converted to a pointer to the first element of the array. Array notation (e.g. a[1][2]) is always expanded into pointer arithmetic (e.g. *(*(t+1)+2)).

However array notation in declarations and definitions is something else entirely. An array declarator describes an "array of T" type where the values of this type are sequences of elements of type T. A definition of an array object is all about using convenient and easily understood array notation to allocate the appropriate amount of storage for the desired array of objects such that the array identifier refers to this storage without it looking like a pointer. In effect array notation in a declaration or definition is a macro generating an expression using sizeof() and arithmetic, and in the case of a definition, the equivalent of alloca() for auto arrays or its equivalent in the linker for global arrays, and doing it all at compile time (well except for C99 variable-length arrays).

The use of array notation in expressions and the use of array types is not so tightly connected, though it is tradition and idiom to use array notation in expressions to reference storage in objects declared and/or defined as arrays. You can just as easily use array notation with a pointer type in order to make the pointer arithmetic cleaner and more meaningful. Indeed in C an expression of the form e1[e2] is precisely equivalent to the expression *((e1)+(e2)). The usual binary conversion are applied to the two operands, and the result is always an lvalue. Since the indirection operator (*) must have a pointer as its operand, one of e1 and e2 must be a pointer and the other must be an integer, but it does not matter which since the initial unary conversion for any "array of T" is to convert it to "pointer to T". Array notation in expressions is in effect a compiler (language-level) macro to generate pointer arithmetic expressions.

So really C already does work the way you suggest but you are confusing the use of the notation in two very separate contexts.