Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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)?

share|improve this question
4  
Why have char when you can achieve the same thing with byte? –  WuHoUnited Oct 20 '11 at 23:43
2  
On a more serious note though, how do you intend to accomplish the memory allocation with a pointer? –  WuHoUnited Oct 20 '11 at 23:46
2  
Personally, I think of pointers as (sometimes) pretending to be arrays rather than visa versa. In many other languages, pointers don't have array-like behaviour - if you want to access an array through a pointer you either use a pointer-to-array type or you do pointer arithmetic (counting in bytes, not elements). I'd bet a fair amount of money that the inventors of C thought in terms of tweaking pointers to get more convenient array-like behaviour - I very much doubt they already had array-like pointer behaviour then decided "I know, lets add arrays too". –  Steve314 Oct 20 '11 at 23:50
    
Good points. Thanks. –  daniels Oct 20 '11 at 23:52
1  
Why have 0xAB when you can achieve the same thing with 171? –  e-MEE Oct 21 '11 at 5:23
show 3 more comments

5 Answers

up vote 8 down vote accepted

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.

share|improve this answer
    
Oh, and pass by value for foo1, foo2... gets messy quickly, especially if you want to allow a variable number of members. –  kylben Oct 21 '11 at 0:19
    
good point, thanks –  daniels Oct 21 '11 at 0:27
1  
Only arrays declared as automatics end up on the stack. Anything else (i.e., statics) usually ends up elsewhere depending on on the environment. –  Blrfl Oct 21 '11 at 10:48
    
It is not a "syntactic sugar", it is much deeper - an important part of the C type system, as well as the infamous array decay. –  SK-logic Oct 21 '11 at 10:52
    
what is the difference between an array on the stack and alloca() –  sylvanaar Oct 21 '11 at 11:33
show 2 more comments

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.

share|improve this answer
1  
As I mention in the question, I am not against the array notation. But that same notation could work on top of pointers, so where's the need for arrays themselves? –  daniels Oct 20 '11 at 23:21
1  
@DanielScocco - Maybe it could. But it was made like this, nevertheless. End of story. No one can really answer this, as no one knows what was going in the author's head at that time. –  ldigas Oct 21 '11 at 0:05
add comment

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.

share|improve this answer
    
Show us the difference in assembler. Multidimensional arrays, structure packing and padding they are all just ways to provide a frame of reference that makes sense to the humans who have to make sense of and use the language. –  sylvanaar Oct 21 '11 at 11:55
    
@sylvanaar are you serious? do you really need to see the assembler to be sure that first structure holds space for two integers and a float, and the second one just for storing a memory address and a float? –  fortran Oct 21 '11 at 11:59
    
@sylvanaar and by the way, declaring structures does not generate any kind of assembly code, what you could see is that accessing the float field is done with a different offset (in case that 2*sizeof(int) is not the same as sizeof(*int) that could be the case) –  fortran Oct 21 '11 at 12:01
    
I rattled my comment off quickly - didn't want to come across as being rude though. Declaring structs and arrays does create static memory allocations in the compiled image, except for unitialized array declarations. However my point was that arrays don't let the compiler do anything magical that you couldn't do yourself since you have access to the same instruction set. –  sylvanaar Oct 21 '11 at 13:36
1  
"Declaring structs [...] does create static memory allocations in the compiled image" No, declaring a variable (of struct type, or any other type) does this. Declaring a struct just tells the compiler how big that type is and what offsets each of its members are; you might never allocate one, or only allocate them as local variables. –  Random832 Oct 21 '11 at 15:40
show 1 more comment

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

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

share|improve this answer
    
You would still be able to use that even if we just had pointers, wouldn't you? The compiler would just have to know what to do. –  daniels Oct 20 '11 at 23:23
1  
@DanielScocco and how would it know what to do? arrays –  ratchet freak Oct 20 '11 at 23:41
    
Agreed - what would you call the feature that reserves space for a sequence of same-type items as a local or global variable, if not an array? A pointer type is a pointer type - it doesn't specify whether what it points to is a sequence, or what sized sequence. –  Steve314 Oct 20 '11 at 23:45
2  
@DanielScocco What comes with an array that doesn't come with a pointer is information about the size. So a (pointer, size) pair or a (pointer, pointer) pair can indeed hold just as much information as the name of an array. Whether this means that arrays are pairs of pointers (or vice-versa) seems more like a metaphysical question, so I'm not really interested in answering that. (The answer is probably no as pairs of pointers look more like slices, and hence can do more than just refer to an array.) –  Luc Danton Oct 21 '11 at 0:40
1  
@Daniel Scocco, arrays has a size. You can allocate an array on stack, you can put an array into a contiguous structure, you can use it within a union. If the array type did not exist, it would not be possible. –  SK-logic Oct 21 '11 at 10:51
show 2 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.