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.
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.
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.
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.
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:
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.
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.
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.
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