How to teach pointers to beginners in C? [closed]

tl;dr: It's all about the pictures.

C Programming for non-majors is the first class I ever taught. I had good luck with pointers by introducing them as a concept fairly early and letting them sink in as not-scary. Then I snuck in progressively more complex examples over the semester without drawing too much attention to the pointer syntax (other than as a reminder of how it works). Instead, we focused on "see, we're solving more useful problems - you're writing real code now! (oh, and you're using pointers quite a lot but don't mind them)."

Addressing your specific points:

The difficult part: How does a pointer work? Or: How to explain a technical problem to non-technical people?

This is where I started drawing many pictures.

One of the first was a sketch of a spinner from a board game (i.e., that needed random numbers but didn't want to use dice): that's usually something that everyone in the room could relate to. The needle (it's not really a needle but I didn't want to say "pointer" too soon) in the center is a physical thing. It can only point to one box at a time. The boxes are all separate from each other. Each box held a number. We could spin it and ask "what number is the needle pointing to?"

At this point, the whole room would be nodding when I would say that the C language contained both concepts: memory for holding values (i.e., the boxes) and pointers for indicating a particular memory "box."

Very short introduction what a pointer is and how it is denoted in C. (* and & operators )

At this point, since we were all comfortable with the idea of arrows AKA needles AKA pointers and the memory AKA boxes that they could point at, we could write some simple one liners and draw the pictures that are their equivalents.

NOTE: This is where class participation became critical quickly: "but what if I want to ...?" meant that the room was engaged. Pictures, pictures, code and more pictures!

We would generally start with simple examples:

int x = 1; // A box with a 1 in it
int y = 2; // Another box way over on the other side of the board with 2 
int z = 3; // Yet another box with a 3

int *p = &x; // See everyone?  All this does is make the arrow that points at box x
int *q = &y; // A pointer that points at y

printf("%d", *p); // "What's in the box that I'm pointing at?" => prints a 1
p = q; // Ooo, now both arrows point at box y
printf("%d", *p); // "What's in the box that I'm pointing at?" => prints a 2

*p = 5; // What does this do, everyone?  If I printed *q, what would I see?

... and so forth. The critical point was to drill the syntax home. Practical examples came later after everyone was clear on the mechanics.

I think of pointer syntax as being at least as important for introductory C programmers as the difference between = and == (or worse, & and &&). If you can't even read the syntax, more interesting problems will be impossible to solve.

When I was taught about such things, the best approach to me was to draw it out.

Draw out a line of boxes. These are the memory "cells". At this stage we can gloss over the differences between static, stack and heap memory. You don't even need to go into details of how many bytes a variable needs.

Each box has an address - a simple number on all modern computers. So write a series of numbers next to the boxes.

If I declare a variable, int foo = 5;, then the compiler allocates a box, puts a label "foo" on it, and puts the value 5 into the box. Let's say this box has address 1000.

If I declare a pointer, int *fooPtr = &foo;, then the compiler allocates another box, puts a label "fooPtr" on it, and puts the address of foo into it - i.e. 1000. The unary "&" operator is "get the address of".

The unary "*" operator is "get the thing pointed to by". So if I write printf("%d", *fooPtr);, then it will look in fooPtr, see the value 1000, go to the box with address 1000, and fetch the value 5 from it.

That's pointers in a nutshell.

Pointers-to-pointers, arrays and pointer arithmetic can later be explained using the same line of boxes analogy.