What's a nice explanation for pointers? [closed]

Question

In your own studies (on your own, or for a class) did you have an "ah ha" moment when you finally, really understood pointers? Do you have an explanation you use for beginner programmers that seems particularly effective?

For example, when beginners first encounter pointers in C, they might just add &s and *s until it compiles (as I myself once did). Maybe it was a picture, or a really well motivated example, that made pointers "click" for you or your student. What was it, and what did you try before that didn't seem to work? Were any topics prerequisites (e.g. structs, or arrays)?

In other words, what was necessary to understand the meaning of &s and *, when you could use them with confidence? Learning the syntax and terminology or the use cases isn't enough, at some point the idea needs to be internalized.

---

Update: I really like the answers so far; please keep them coming. There are a lot of great perspectives here, but I think many are good explanations/slogans for ourselves after we've internalized the concept. I'm looking for the detailed contexts and circumstances when it dawned on you.

For example:

I only somewhat understood pointers syntactically in C. I heard two of my friends explaining pointers to another friend, who asked why a struct was passed with a pointer. The first friend talked about how it needed to be referenced and modified, but it was just a short comment from the other friend where it hit me: "It's also more efficient." Passing 4 bytes instead of 16 bytes was the final conceptual shift I needed.

Answer 1

Memory-as-a-Grid Diagram

Usually what I do is represent memory as a "grid", so that I can make up addresses, highlight different memory spaces and write in the cells values (or even further, their binary representations) and link the pointers in memory to the values they point at. (And then still mention that it's a simplification).

Usually it's a "ohhhh" moment for most of my students.

Symbol Juggling

Then when it comes to have them stop forgetting how to use & and *, it's very simple: present it the same way they do math or physics calculations. If you divide a distance in km by a time in hour, you get a speed in km/h. What's in needs to be out. Simple.

printf to the Rescue

Doing just a few basic examples that visually represent what you explained with these will comfort them in what they think they understood, or give them the opportunity to say "ah, I don't get this one".

Be Extensive

Cover pointers for simple types and make sure they understand the difference between addressing and the size of a data type, then structs, then arrays, and multiple levels.

Then start pointer arithmetic.

---

Addendum: Recursion

I usually explain recursion similarly, using a visual representation. Have them print the alphabet using a pre-made function that writes a single char, and then ask them to print it in reverse order by just changing two lines.

Usually there's a "what the...?" moment, and when you add just another parameter to your printf to print numeric values and indent the steps, it becomes a sigh of relief.

---

Alternatives: The Play-Doh Model and the Water Cups

I actually had some co-workers in a university who showed students a video explaining pointers and memory accesses using play-doh paste. It was incredibly clever and well done, though I never really used that technique myself, except for very young learners interested in grasping programming (but usually those I wouldn't lead them towards a language using pointers too early). Basically using tiny balls of play-doh which you can attach to other bigger balls of play-doh representing memory spaces, and that you can combine together to either link them (like in a linked data structure) or merge together (as in a contiguous memory space). Using different colors for the memory spaces pointed to and the pointers help as well. But I still think the Memory-as-a-Grid thing works better, as you can clearly show that the pointing is really a matter of "addressing", as on a "map/grid". Whereas the Play-doh mode still confuses them into thinking that things really "touch" each other in memory.

The Water Cup thing was used directly by a colleague as well, but I don't know if she came up with it. It was an interesting approach, but I noticed many students were left puzzled by the explanation. Something alike to DevSolo's Coffee Cup technique. But I think it's actually a misleading one as you make the students confuse containers, data structures, pointers and arrays. It might be an interesting approach to explain arrays at the beginning I assume, but I wouldn't stick to it very long.

Answer 2

Someone much wiser than I once said:

The nun Wu Jincang asked the Sixth Patriach Huineng, "I have studied the Mahaparinirvana sutra for many years, yet there are many areas i do not quite understand. Please enlighten me."

The patriach responded, "I am illiterate. Please read out the characters to me and perhaps I will be able to explain the meaning."

Said the nun, "You cannot even recognize the characters. How are you able then to understand the meaning?"

"Truth has nothing to do with words. Truth can be likened to the bright moon in the sky. Words, in this case, can be likened to a finger. The finger can point to the moon’s location. However, the finger is not the moon. To look at the moon, it is necessary to gaze beyond the finger, right?"

Answer 3

I found that diagrams were very helpful. Example:

This sort of diagram helped me see that pointers were their own variable, but contained a value that was the location of another object, i.e. array or string. Also, when done in pencil, I could use it to trace my program on paper, or on a chalkboard/whiteboard.

Answer 4

When I first "learned" about pointers, I was sort of thrust in to it. My university had made the decision a long time before I enrolled to center the curriculum around Java, so when my Data Structures professor gave one lecture on C and asked us to implement an XOR-List with pointers I felt like I was getting in to something way over my head.

I understood the definition:

A pointer is a variable that contains an address of a variable

But I still didn't understand a large part of the concept. Looking back, I think it centered on three things:

1. What exactly is a memory location? (At the time I didn't take a Computer Organization class)

2. The awkward syntax (So um... why exactly is it defined like "int *ip" but then subsequently I refer to the variable as "ip"?)

3. How exactly is it beneficial to store the address of a variable rather than just use the variable?

It wasn't until I purchased the K&R book and completed every problem that I really got a grasp for pointers. Besides the fact that I had long completed the Computer Organization class (that I think should be required before learning C), part of it had to do with the fact that I realized that pointers can be used for functions, arrays, structs... to do useful things and not merely as storage for addresses of ordinary variables.

But my "aha" moment by far was the way that K&R explained the awkward syntax of defining a simple pointer. I took notes throughout the book (in which I rephrase points made by the book in to my own words in order to further my understanding), and this is the one relating to that:

A pointer is a variable that contains an address to a variable. A pointer is both defined and dereferenced (yielding the value stored at the memory location that it points to) with the '*' operator; the expression is mnemonic.

Ex.: 
   int a;      /* Variable 'a' is an integer */

   int *ip;   /* Variable ip is a pointer and dereferencing it gives an integer.
                 In other words, the expression *ip is an int, so ip is a pointer
                 to an int */

I had always felt that I couldn't fully grasp the more advanced concepts of pointers until I had something so elementary ingrained in my head. It had bothered me endlessly after that assignment (which I didn't do too well on, by the way ;) ) why "*ip" did not exist right after I (thought I) defined "*ip". Mastering this is essential for more advanced concepts involving pointers, like function pointers and more complicated definitions like this:

char (*(x())[])()

All in all, I think the concept of pointers requires:

1. A basic understanding of how memory is laid out in a computer (and what memory is).

2. Knowledge of how powerful pointers can be (real world usage, not just another abstract concept that they learn for the sake of learning).

3. Deciphering the hieroglyphics colloquially known as "a definition of a pointer"

So all in all, I think there should be at least 3 "aha" moments when learning about pointers. I'm still a student so I thought you'd appreciate the viewpoint of someone who's still (relatively) fresh off learning the concept.

Answer 5

Pointer are a bit like the application shortcuts on your desktop. Delete the shortcut and the target still exists. Start up the shortcut and the target gets started.

I always explain the working of this by simple creating a txt file on my desktop and two shortcuts to the file. After copying and deleting the shortcuts you can see people understand the idea behind 'references'.

Once the group understands the basic behind the shortcuts you can start explaining pointers anyway you want. They'll probably understand it pretty easily.

Answer 6

8-10 years ago, I taught an intro "C" course at a community college. This was always a fun topic to explore. What seemed to work best, and this was after discussing w/ a co-worker a few times was to use a coffee cup and your hand.

I used the analogy of a coffee cup (or row of them for arrays) to as a variable (it can hold something). I then used my hand, which could also hold something or, by extending my index finger to "point to" a coffee cup.

A close hand was null, a finger pointing at my head (like a mock gun) was a dangling pointer.

Then with a few demonstrations and trips through the debugger, it clicked with most.

Answer 7

I really get quite worried when I hear the "how did you get a grasp on pointers" question. I always thought the concept was incredibly simple, and a logical evolution of languages providing great power to the programmers.

The thing which worries me is that I never found it difficult to understand the concept of pointers. So when you here "when did you finally get it" over and over again, you start thinking:

Do I actually get it? Maybe I never did?

Maybe the reason why the concept seems to be a tricky one, is because we keep telling everyone who has yet to encounter them that pointers are so difficult, and here are a hundred ways in which you can learn?

Just throwing that idea out there, of course personally I love a good diagram and Steve Gibson always does a fantastic job of explaining anything!

Answer 8

I never had much of a problem with pointers in C, but that may be because I had to learn assembler first. It was actually a relief not to have to manage addresses myself any more. So maybe the answer (assuming this is something you're teaching) is to give students an emulated assembly language to work with. They will figure it out in the process of writing anything more sophisticated than "Hello, world."

Answer 9

How I really learned about pointers? By writing a simple compiler freshmen year of college.

How to explain pointers in layman's terms? I like the (dated?) analogy of a library catalog stored on index cards. Each card ("pointer") contains information about where some book ("data") is located, but doesn't actually contain the book itself. If you modify the card ("pointer arithmetic"), all it does is change what book it points to and has no impact on the book itself - just be careful not to screw up the address or you might point to a non-existent book or even the wrong library. However, if you follow the "address" on the card and go to the proper part of the library ("dereference the pointer"), you can see/modify the book itself.

Answer 10

A pointer is a variable whose value is the memory address of another variable.

Answer 11

I shall assume someone going to learn pointers knows what the normal variables are and how they work in C. Now, let's try to define pointers with some of it's attributes-

• They are also variables, but of different nature. Assume there are two layers in the variable space. The normal variables of different types resides in the upper layer and pointers in the lower layer. Like this figure-

  

• As the name 'Pointer' suggests, pointers can POINT to something. Like our finger can point to some object. What are the things they point to? These are the normal variables. In short, "Pointers point to normal variables".

• Like normal variables, pointers also are of same number of types like int,char or float. And a pointer of a specific type can point to only same type of variables.
• A pointer can point to one variable and later the same pointer can point to another variable. Just the type should be same. So, the a pointer's association with some variable is not permanent and can be changed.

• So, how a pointer is declared? Almost like normal variables. You have to precede the name with an asterisk(*). Like-

  int *pointer;
  

• Then, how a pointer is associated with a variable? Using the & operator before the variable like this statement-

  pointer = &variable;
  

• How a pointer is used by pointing to a variable? This is also done by preceding the name with an asterisk(*). Then it can be used in the place of the variable it's pointing now-

  *pointer = var1 + var2;
  

  instead of

  variable = var1 + var2;
  

• Now, play with pointers with some code. Just get used to this characteristics of pointers now. Upto this point, we are talking about what pointers do. Once you are ok with it, then start studying how pointers are pointing to some variable and how they react if normal arithmetic operations are applied on them. Then go for the relation between pointers and arrays and pointers to pointers.

That is all I shall suggest about learning pointers.

Answer 12

Edited in support of the revised requirement of the question

My path to "post-pointer" understanding (if I recall correctly) went like this. I had some simple experience of assembly programming from when I was still mucking around with a BBC Micro so I had the concept of memory as a bunch of boxes (see below for this). This was reinforced by the use of arrays. However, I was going into the world of C and had to deal with strings and that meant pointers. In BASIC this was trivial, in assembler I never had to work with them, and now in classic C it's all pointers and stuff. Ah, but I can scuttle back to arrays with (null terminated) strings like this:

char s[] = "Hello, world!";
printf("%s",s);

All well and good, that's just an array of chars (8 bits per character in my little world) with a zero character at the end to show where it ends. The printf just takes that array and runs over it printing it. But what if I want to pass this string into a function?

void print_str(char* p) {
  printf("%s",p);
}

Is what the manual says, but what's that * all about? Hmm, char* means "pointer to a char". OK... lost me. Then it dawned on me that the char* makes p equivalent to s[0]. OK, I can use that, but I still haven't twigged what pointers are. I mean, how do I set some data with one of these things? Off to the manual again...

char* p = "Hello World!";

As I write the above I'm saying to myself "declare a pointer to a char and set it equal to this array of characters". Somehow that pointer does away with the need for an array. Guess it's the compiler doing some stuff for me for a change. So how can I change the array with this pointer? I know that I could use the array version

 s[2] = 'L'; 

but what's the equivalent in "pointer speak"? Off to that manual again...

*(p+2) = 'L';

I suppose that * simply means "the contents of the memory address" and (p+2) is s[2]. Which meant that the pointer p was... just... an... address... bong!

That there is the sound of enlightenment. I suddenly twigged pointers (it was a long time ago, we old timers didn't "grok" until later). It was just indirection.

---

Original:

OK, my 2c worth:

Imagine memory is a bunch of boxes. Each box has a number on the side (the address). Each box contains a number (the contents). You can work with these boxes in 2 ways: variables (I want the contents of box N), pointers (I want the contents of box whatever is in box N ). Pointers are simply indirection.

And for the big answer that covers everything you will ever need to know - read this.

Answer 13

Get some little blocks of wood.

add metal hooks to one end, and metal eyes to the other.

you can now do a linked list in stuff you can play with.

Try explaining with this physical prop. I often wished I had this when teaching pointers to first year ( freshmen) students.

The little metal hook is the pointer, the block of wood the thing pointed to.

I DEFY anyone to not get it after playing with the blocks.

Answer 14

I made my life easier when I just removed all the fluff and started treating pointer as any other variable rather than some magical entity (long long ago in grade 11).. just know 3 things:

1. Pointer is a variable that store the address of another variable (or just any address).
2. * is used to get the value at the memory location that is stored in the pointer variable.
3. & operator gives the address of a memory location.

The rest is syntactic sugar and common sense.. Just write some simple C programs (like implementing a linked list library) using pointers to get a hang of it.

Answer 15

1. Pointer can be thought of as a generalization of an index into an array.
   • Consider that a big array can be chopped off into a number of smaller, non-overlapping, variable-sized arrays. Now, these smaller arrays are what we usually think of as array. The bigger one is then the computer's entire memory space. The process of chopping off smaller arrays is called memory allocation.
2. A set of structures which are linked together by some pointers can be thought of as a directed graph.
   • Each vertex is a variable which can hold some value.
   • Some variables are pointers, and each pointer can have exactly one outgoing edge into something else.
   • Variables which are not pointers will not have any outgoing edge. They could have any number of incoming edge.

Answer 16

I cant quite remember the circumstances around my pointers-aha-moment, but I have retroactively refitted the memory around my understanding of a c-style array. (i.e. arr[3] is the same as *(arr+3) )

For some reason I find it immensely helpful to view pointers as arrays whenever I happen upon a pointer-situation.

Answer 17

Basically @Gary Rowe introduced the right model. Memory as a set of boxes with addresses (numbers) on them. Each box stores a value (number).

The idea of a pointer is to interpret the value in one box as the address of another box. This value is used to refer to a specific box, which is why it is called a reference. Thus dereferencing is the process of opening the box that is refered to.

if v is a variable (box), then the statement

• v means value of v, i.e. give me what is in the box
• *v means dereference the value of v, i.e. give me what is in the box refered to by the value of v
• &v means reference v, i.e. give me the address on box

I think it doesn't server the purpose of introducing pointers as something completely different. It was a concept hard to grasp for me when I was a kid. It always seemed like some dark magic I never truly understood, that needed a lot of special characters. The first time I did understand was when I wrote a small game using double indirection in a language that doesn't have pointer arithmetics. That enlightened me.

Pointers are a matter of interpretation. I think explaining that makes things a lot easier. And pointer arithmetics are extremely simple and intuitive operations if shown a simple example with a memory of 10 variables.

Answer 18

The explanation that i really grocked was:

Consider a city grid with different houses built on pieces of land. In your hand you hold a piece of paper. On the paper you have written:

---

David's house,

112 So and so street.

---

The piece of paper (pointer variable) contains an address that points to David's house. When you want to tell a friend to have a look at David's cool house it is much easier to use the pice of paper as a reference to the house than to send the actual two story building in the mail.

As with real pointers you can get into some trouble when you follow the address on your piece of paper. David could have moved and when you get there you just find a big hole in the ground. In this case it would have been better to erase the address on the paper when David moved or at least change it to the new one. You could also find that you go to the address and enter what you think is your friend David's living room but this time you end up in a complete strangers swimming pool. Someone else has used the space at the address you had for something completely different.

Answer 19

If you want to explain pointers you have to explain memory first. I usually do that using graph paper/squared paper with rows and columns. If the "student" understands memory she can understand what an address is. If you got address you got pointers.

You can play with this abstraction. E.g. write the address (number) of one square into another square. Now draw an arrow from the pointer square to the destination square. Now overwrite the pointer (e.g. increment it) and adjust the arrow. Write an address into another square and let the student draw the arrow...

Next step: Give certain squares (like the pointer) a name. Now you can explain dereferencing. That's it.

Answer 20

Perhaps it's just me, but I work well with analogies. So let's say you have a friend (function/class) "Foo", who wants to have someone else (different function/class), "Bar", contact you for some reason. "Foo" could take you to go see "Bar", but that's not convenient, moving all those beings (instances) around. However, "Foo" could send "Bar" your phone number (pointer). That way, no matter where you are, "Foo" knows how to contact you without having to find you.

And, let's say "Bar" has an acquaintance, "Baz", who also wants to get in touch with you. But you're protective of your phone number and you don't want everyone to have, "Baz" can call "Bar" (phone as pointer), who can then forward the call to you (another pointer). And so on and on down the chain of "Baz"'s friends and friends of friends.

Answer 21

Pointers make way more sense if you've studied assembly language and/or computer architecture. I think that if I teach a C class, I would start with a couple weeks of architecture to explain the memory model and the kinds of instructions the processor actually executes.

Answer 22

My "aha!" moment came in this tutorial:

A Tutorial on Pointers and Arrays in C

To be exact, it came in this chapter: Chapter 3: Pointers and Strings

To be even more precise, it came with this sentence:

The parameter passed to puts() is a pointer, that is the value of a pointer (since all parameters in C are passed by value), and the value of a pointer is the address to which it points, or, simply, an address.

When I read that, the clouds parted and angels blew trumpet fanfares.

For, you see, every C tutorial or book I'd read prior to that had asserted that C could pass by value or by reference, a nefarious lie. The truth is that C always passes by value, but sometimes the value passed happens to be an address. Within the method, a copy is made of that address, just like a copy would be made of an int passed in. A copy is not made of the value to which the pointer points. Thus by using the pointer within the method you can access the original value and change it.

I never became a C programmer, but I became a .NET programmer, and objects and object references work the same way; the reference to the object is passed by value (and thus copied), but the object itself isn't copied. I've worked around many programmers who don't understand this because they never learned pointers.

Answer 23

The trick is to explain that the location of a thing and the thing itself are not the same, just like a picture of a pipe is not a pipe. When you move a thing, its location changes. The location remains and some other thing can be put there.

Answer 24

A pointer is a sticky note that tells you where something useful is. It contains the location of the thing and tells you how big the thing is (in C, anyway). So a double pointer is like a sticky note that says "There's a six pack in the fridge". You have to actually go get the six pack to figure out if it's Coke or Budweiser.

Answer 25

Given the code :

int v=42; // declaring and initializing a simple variable

int *p = &v; // creating a point p to the variable v

Following can be said about the above code:

int * p // "int pointer p" ... this is how you declare a pointer to variable of type int

*p // "pointed to by p" ... that is the data that p points to, its same as v.

&v // "address of the variable v" ... this represents the literal value for p

Answer 26

http://cslibrary.stanford.edu/

This site has great tutorials for learning pointers and memory management .

I would suggest you to walk through pointers basics, pointers and memory given on the site. You can also look at linked lists problems given on the link to further strengthen the pointer concepts.

Answer 27

The key to explaining pointers is making sure that the people you are explaining to, already have an understanding of the concept of memory. Whilst it would be nice if they really understood it low level, believing that memory exists as a massive array, and understanding that you can access any position in the array by its index location is enough.

The next step, having the concept of passing the index location rather than copying the entire memory makes sense to most people. And that is enough to allow most people to understand why pointers are useful.

the final step to understand pointers is to explain how you can pass in as a parameter a memory index location for the method to store the index location for where all the data is stored. I have found that this can be step too far for some people to cope with.

Once someone has grasped these basic steps its straight forward for them to grasp that you can chain pointers indefinitely, just as long as you keep track of how many times you need to look at addresses to find the actual data object.

Once someone has grasped pointers, the next thing that they must grasp quickly is the difference between heap memory and stack memory, and why pointers to stack memory are dangerous when passed outside the method.

Answer 28

I remember a book "C puzzles" or similar, which I read purely because it was one of the few programming/computer related books available in the library, my understanding of C was rudimentary. It threw a C expresison at you, and asked to explion it, getting more and more complicated.

Answer 29

When I was in university, my professor had some really neat powerpoint slides depicting a point as a separate variable on it's own with an arrow to a memory location (represented like an array) and when we were doing Linked Lists, he would do it step-by-step, showing when the arrow changes, when the pointer is dereferenced etc..., there was no way one could not understand it within a couple of minutes. The concept itself is really easy, but doing it right or applying it in practical programs requires more practice.

Answer 30

Before I do that, I explain that in programming "everything uses memory", and (static) variable allocation in memory. I will also explain what a memory address is, and the relation between memory space, memory address and variables.

Finally, I explain that there are integer data type and variables, string data type and variables... and so on, until explaining that there are an special data type that stores memory addresses, that has an empty value like 0 o "", called null.

And, finally, dynamically allocated variables thru the usage of pointers.