When teaching C, is it better to teach arrays before or after pointers?

Question

For those of you with curriculum development experience: what is the best strategy regarding arrays?

I have seen some schools that teach arrays after variables and control structures, often before even teaching functions. This allows teaching of some rudimentary algorithms, etc. However, it then brings the problem of how to pass arrays to functions, so it is necessary to go back to arrays pointers are taught and patch things up.

Another option is to go from variables and control structures to functions, and then teach pointers, and once you have pointers, teach arrays from scratch, and then use that to get to dynamic memory allocation.

To me the second option makes more sense, because unlike simple variables, with arrays it is easy to "go out of bounds", but students who did not yet learn about memory and pointers may not understand what lies outside these bounds.

However, I'm interested to know what others think.

Answer 1

I think the best approach is to introduce 1 concept at a time. You don't need to 100% explain arrays in the first module. You can detangle almost anything by introducing 1 concept at a time.

I would teach them in this order: Arrays, Pointers, Arrays+Pointers, OtherStuff[N].

---

Arrays:

You can teach simple arrays first so they understand the ability to have multiple data slots accessible from a single variable name.

//The following doesn't need an understanding of pointers
int x[10];
x[0] = 5;

---

Pointers:

Then you can teach about pointers and how they work, starting with some simple examples:

int y = 5;
int *p = &y;
*p = 6;
printf("%i\n", y);

Make sure to give a special emphasis that a pointer is just like any other variable. It stores a memory address.

There is no need to get into the stack vs heap just yet.

---

Arrays+Pointers:

How to iterate over arrays with pointers:

int x[10];
x[0] = 5;
x[1] = 6;
int *y = x;
printf("%i\n", *y);//prints the first element
y++;
printf("%i\n", *y);//prints the second element

---

Then you can teach more complicated things...

• How to do pointer arithmetic.
• Array + i shorthand for array[i]
• Passing arrays to functions as array pointets vs pointer param + size param
• How arrays are continuous blocks of memory
• Explain string literals, buffers, ...
• How sizeof works with pointers vs array types (pointer size vs buffer size)
• Explain more complicated concepts like allocating memory, the stack, and the heap
• Multiple levels of indirection
• References
• How multi-dimensional arrays work
• ...

Throughout all examples make heavy use of sizeof and printing addresses. It really helps to understand what's going on.

Answer 2

They should be taught at the same time.

The example of a single dimensional array being accessed as a pointer to the base with offset (typesize * index) should make an appearance.

i.e.

a[i] is equivalent to *(a + i)

Answer 3

I would teach pointers first. They can be explained without teaching arrays. While teaching arrays i could then refer to pointers when explaining the expression a[i], and when explaining how one can pass them to functions.

Answer 4

Don't overthink things.

Teaching these concepts as clearly and engagingly as possible is FAR more important than what order you do them in.

I would suggest touching on the basics of arrays first, and doing pointers and revisiting arrays (more fully this time around) later.

Answer 5

Depends what they know. Are you teaching C, or programming-and-C?

I've seen very little success with the latter. C is simply not a very intuitive or forgiving language. I haven't seen students been thankful for starting with it, though I've seen students frustrated with programming for it.

The ones who are going to stick with programming will go out and learn C in their spare time, anyway. There's no need to push it on them first.

If you're just teaching C, and they already know pointers and arrays, then teaching how pointers and arrays work in C can be done in one lesson.

Answer 6

You should teach arrays first, because they exist in almost any other language, and are easier to understand. Pointers, or some aspects of pointers, build on what was learned about arrays. This is the organic order, imho, and how I learned it way back when.

Answer 7

I'm assuming you are teaching C to students who already know how to program in another language like Java (or back in my day, Pascal). I don't think C is a good language to use for teaching programming to complete novices.

I would teach pointers first. This is one of the important new ideas that that will be learning in C. They will already know the concept of arrays from other languages, so there's no urgency to teach this first. So when you do cover arrays in C, you can talk about how they are essentially syntactic sugar for pointer arithmetic, a concept they are now familiar with.

Answer 8

I teach pointers before I worry about arrays. However, typically, the students I see, they have already been exposed to arrays in their first CS class in some other language. However, even I were teaching C in the first CS class, I'd do pointers before arrays and describe arrays in terms of pointers. Just because it is fashionable these days to think "no one will ever need or want to know how computers actually work" doesn't mean it's true.

Answer 9

As stated above I don't think the order is important, but this is the order I wished someone would have showed me the stuff.

1. Arrays
2. Pointers
3. How Arrays and Pointers are the same
4. Why Arrays and Pointers are NOT the same

For more info on point 4 I really recommend chapter 4 "The Shocking truth: C arrays and Pointers Are NOT the Same!" in "Expert C, deep C secrets".

/Johan

---

Update:

Some links to the book, and there is also a preview of the book. http://books.google.se - Expert C, deep C secrets

And the user comments about this book is true: http://www.amazon.co.uk/Expert-Programming-Peter-van-Linden/dp/0131774298

Answer 10

Would you teach pointers before strings?

Probably not. And most of the same arguments apply.

(But generally I agree with @legion — don't overthink it.)

Answer 11

If they've been exposed to assembler beforehand, teach pointers first.

If they've been exposed to higher level languages (ie just about anything) teach arrays first.

In my experience people coming to C without some exposure to assembly level programming (registers, addresses, "computer fundamentals") are about to enter a world of pain. IMHO you're actually better off teaching assembly level coding first, then introducing C as a better assembler.

Answer 12

I think it would be better start with arrays, because the concept of array is simple and intuitive, but in C it would be important revisiting arrays after teach ponters, as 'Legion' suggested before.

Answer 13

This question can be asked for any object-oriented language really.

When I was taught Java, I was first shown arrays and the pointers, as the last part of arrays, to demonstrate the difference between a deep copy and a shallow copy.

Answer 14

Interesting question - I hope it's not too late to answer.

When I taught programming at Boston College in the early 80s, my colleagues and I wrestled with these issues every year, and we kept tweaking our approach. C was a new language then, so our progression went through Basic to Pascal. I remember thinking at the time how hard it would be to teach C just because it was more loosey-goosey, there were more ways for students to mess up, and more really confusing things like the distinction between arrays and pointers that you had to teach.

What I found most useful was to try to be concrete, not abstract. For example, in the intro programming course I used an interpreter for a simple decimal computer that you would program in it's decimal "machine language". It had addresses going from 0 to 999, and opcodes like 1234, with the "1" meaning "add to the accumulator", and "234" being the address of where to find the number to add. Students would write really simple programs, like to add up a list of numbers, and they would single-step them, observing what happens at each step.

I would have them play with this for about 3 weeks, and then start into BASIC. In the second course, they would go into Pascal. What that little decimal "computer" accomplished was to convey some concrete concepts that make the "abstractions" in "real" languages a lot easier to understand, such as:

• What memory is, and what addresses are, and how both data and programs are just numbers at addresses in memory. That makes the concept of "variable" and "array" and "pointer" much easier to explain later.
• How the basic model of computation is that very simple steps are performed in sequence, and before each step can begin, the previous one has to finish. I know people will object that computers are highly parallelized and pipelined nowadays, but I have to explain that you need to start really simple, because when newbies see a program run, it looks for all the world like it does everything at once, and reads your mind in the process.
• How, by combining a very small vocabulary of instructions, including jumps and conditional jumps, you can get the computer to do almost anything you want it to.

Now, regarding C, I've heard it disparaged as just a cut above assembly language, but I think that's a good thing. It always struck me as a language by experts for experts. I think the ideas of arrays and pointers and structures are very easy to explain if you can just refer back to the underlying machine. Similarly for C++ and object-oriented programming.

So, to summarize, if students understand the underlying concept of how computers work, even if it's a really artificial computer, then explaining higher-level data structure concepts is a lot easier.