Fog Creek Software
Discussion Board

Pointers for dummies

I was just discussing with a coworker the article Joel wrote some time ago about "for some strange reason, most people seem to be born without the part of the brain that understands pointers".

I think I'd like to add to that : "And the people who are born with the part of the brain that understands pointers can't explain it to them".

I can't actually put my finger on any point in time where I thought "Yes, I get it. This is what a pointer is." It just sort of happened, really. I tried thinking of an analogy whereby if you imagine the memory to be a large block of pidgeonholes, each with a bit of paper in it, the pointer is the pidgeonhole and the value dereferenced by it is the paper ... but that doesn't really explain it well enough.

Just wondering if anybody's got a good way of explaining pointers to new programmers - or, indeed, if there even _is_ a way.

Better than being unemployed...
Friday, January 17, 2003

You're on the right track.

Honestly the best way to teach someone pointers is to teach them about what microprocessors do.  I'd wager there aren't many electrical engineers who do programming work for a living that don't understand pointers.

At least one assembly course should be mandatory for everyone.  This is why I laugh when I hear people say Java doesn't have pointers.  LOL.  In Java, EVERYTHING is a pointer.

Friday, January 17, 2003

I think you're almost there with your pidgeonhole analogy. I'd add that the pidgeonholes are numbered. When you know a number, you can look in the corresponding pigeonhole and read what's written on the piece of paper inside.
And the clever bit is that the piece of paper can have the number of another pigeonhole written on it.
No need to delve into microprocessor architecture. Even my mom's gardner can understand this!

Friday, January 17, 2003

Having some period of time where you don't really get pointers is part of being a new programmer, I think. One may think that one understands the general idea, but that's not the same as being able to use them well. Ultimately, you have to learn by doing and it can be a slow process involving lots of bad code.

If I were going to explain pointers to a new programmer, I'd probably start by describing memory as a set of boxes that contain values, and pointers as address labels that refer to the boxes. Then I'd run them through some simple examples to illustrate the difference between an integer and a pointer to an integer.

Beth Linker
Friday, January 17, 2003

I would start with the true nature of variables


Variables are characterized by
·    name/identifier,
·    address,
·    value,
·    type

Name gives a label to the memory cell so we may refer to that cell. After all we cannot refer to anonymous things. This is an important principle.

Address identifies the position of a memory cell in a collection of memory cells. Address makes the memory cell randomly accessible i.e. we can access the memory cell directly. We do not have to search sequentially through memory until we locate the named cell, because the named cell has an address.

Value is the content of a memory cell.

Type informs us how to interpret the content of the memory cells.

Friday, January 17, 2003


You are correct of course, but you say “I would start with,” and then you don’t finish.

Care to finish what you started :-)

Practical Geezer
Friday, January 17, 2003

I never got what there is not to get about pointers, so I guess this will exclude me from being a good mentor?

Just me (Sir to you)
Friday, January 17, 2003

Lots of ways to continue if not finish:

realise that in scripting languages the runtime will interpret the value by implicitlyconsidering the type

realise that using variable name on RHS means value, using variable name on LHS of assignment operator means means address

naming principle scales up - normailize for commonality by giving names to common things and reference them : repeated expressions are assigned to named variables and the value referenced by saying the name of the var; common statements are assigned to named functions and and their effect referenced by sayng the function name etc.

Friday, January 17, 2003

`I was coming to that,' the Knight said. `The song really is "A-sitting On a Gate": and the tune's my own invention.'

Friday, January 17, 2003

Better than being unemployed -

Good analogy. Reading it made me think of this extension for times when you might need to explain what pointers can be good for:

Imagine the little bits of paper all piled on the table, not in the pigeonholes and you have to put them in some kind of order--there's going to be a lot of physical paper shuffling. Now that they're in order, say you want to add and delete some of the pieces of paper...more shuffling.

Then contrast that to the situation with all the pieces of paper back in their little numbered pigeonholes. You still need to read the papers, but now you can just trace a path among the pigeonholes and you don't have to move any paper to get them sorted. Insert/Delete? Easy--find the right point in the path and adjust the path to point over to the new piece of paper and back, or to short-circuit across the piece you want to delete.  No more shuffling.

Make sense?

Friday, January 17, 2003

"Just wondering if anybody's got a good way of explaining pointers to new programmers - or, indeed, if there even _is_ a way."

I used a post office, postal address, and mailman analogy when I explained pointers to someone.  I had to create a wierd situation to try and make the analogy work though.

Friday, January 17, 2003

Hmmm, interesting suggestions from everyone. Cheers.

Better than being unemployed...
Friday, January 17, 2003

I'm surprised nobody has mentioned this yet.  I always like to try to explain pointers by using a library analogy.  The shelves (or stacks, if you will -- there's a nice natural pun) correspond to memory, books to data in memory, and the card in the card catalog that tells you where to find the book is a pointer.

Of course, if someone's never been to a library, that would fall down, but should such a person really be programming?  ;>

Sam Gray
Friday, January 17, 2003

And then once they do get pointers you have to explain to them pointers-to-pointers, pointers-to-functions, differences between references and pointers, etc...

Friday, January 17, 2003

I've found the reason most people I work with don't seem to 'get' pointers is that they refuse to diagram what's happening. They've not yet reached the point where they can visualize it without paper, but they just won't draw it out. When someone realizes that they can draw things, it doesn't matter whether they get it on an intuitive level: they can always draw a picture and figure it out, and they'll get there soon enough. But people don't do this. Why?!

Mike Swieton
Friday, January 17, 2003

"I'm surprised nobody has mentioned this yet.  I always like to try to explain pointers by using a library analogy.  The shelves (or stacks, if you will -- there's a nice natural pun) correspond to memory, books to data in memory, and the card in the card catalog that tells you where to find the book is a pointer."

Best analogy EVAR!!!

Friday, January 17, 2003

P.S.  Do you remember to mention that a card from the card catalog can point to either a book or to another card (that can point to either a book or another card (that can point to either a book or another card (that can point to either a book or another card (that can point to either a book or another card))))?  ;) 

I think that's the part that freaks most people out.

It's like when I'm trying to teach a newbie about saving and finding files in the file system - the file/folder analogy hold up until I mention that folders can contain other folders (can contain other folders, etc.) and then comprehension comes to a screeching halt and I see panic in their eyes.

Friday, January 17, 2003

I think understanding the library (or pigeonhole) analogy is just the first stumbling block. I also think that it's fairly easy for most people to overcome since it's just one level of abstraction.

But when you start dealing with two levels of abstraction (pointers to pointers), pointers to functions, or pointers to struct/class members (-> syntax), then it gets more difficult.  You can read several chapters in a programming book much faster than you can assimilate the concepts. So, it can go from still making sense to a garbled mess in your mind in a short span.

Let's not forget the fundamental difficulty of understanding the syntax as well.  From page 122, K&R C, 2 ed:

char (*(*x[3])())[5]

x: array[3] of pointer to function returning pointer to array[5] of char.

So, the toughest things in my opinion are remembering all the syntax rulkes and thinking at a second level of abstraction.

Still Learning
Friday, January 17, 2003

I have no real C or C++ experience besides reading a few chapters from "Thinking in C++" and trying to make standard function dll's for use with VB.

I'm not trying to toot my own horn here, but I have to tell you that just from looking at the posted statement, I understood that *x[3] was a pointer (held in an array) to function *(*x[3])() that returned a pointer to a character array's 5th element char(...)[5].  (me. - is that right?)

I didn't read, the next line because I play games with myself like that.  Back to the main point(er), I think these are great analogies to use, the Pigeon Holes for simplicity and and the Library to illustrate that Books have content as compared to Catalog Cards wich are only pointers.

I don't see what's so hard about it, but then again, I've known people that have a hard time figuring out how to tie their own shoelaces too :)

Friday, January 17, 2003

Nobody has problems with pointers in general, Everybody
has problems with C/C++ pointers in particular.

These are neanderthal and insane because of all the wierd
pointer arithmetic stuff and because there are no primitive
types in C for handling things like arrays or strings.

There are only pointers to memory blocks that the coder
must use to simulate such types by explicitly handling them
as addresses, whereas an actual good language would
handle most such cases transparently.

Lisp and Pascal use pointers all over the place, but I've
never heard a Lisp or Pascal programmer complaining
about pointers being hard.

Saturday, January 18, 2003

This is the tutorial that made me understand pointers:

Most especially this chapter, excerpted very briefly below:

    int puts(const char *s);

"...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. Thus when we write puts(strA); as we have seen, we are passing the address of strA[0]."

What I'd been struggling with up till reading this was that books referred to "passing by value" and "passing by reference" as though C could do either one.  When I read this (C always passes by value, but sometimes the value is an address instead of an int or a float), the heavens opened, angels sang, and C suddenly made a lot more sense.  (It was such a sea change that I even remember exactly where I was sitting when I first read it!)

I think perhaps a big part of the reason so many people don't understand pointers is they only learn out of one book.  I'm working on a CS degree now, and in a new language class I always check out library books or buy one or two books to supplement our class text; having two or three alternate viewpoints helps immensely in clarifying obscurities...especially those which the author has made obscure through bad writing.

Sunday, January 19, 2003

The biggest problem with people understanding pointers is the notation used to represent them. I feel like I have a great understanding of pointers, and it came to me rather quickly. But, when I look at some code (especially someone else's code) those damn asterisks can sometimes make my eyes cross.

The asterisk is used to declare pointers and to dereference them. I think that that's a big big mistake. I think that twice as many people would be able to get a clear understanding of pointer usage if the declaration and the dereferencing used different operators. Or, even better, if you could call a dereference() method to dereference your pointers.

Benji Smith
Monday, January 20, 2003

I think that Benji correctly identified the stumbling block for most pointer newbies:  that the declaration syntax is the same as the dereference syntax.

I don't think that the syntax needs to be changed.  But realizing that it is a common source of confusion and being able to address it and help novices identify it as such is a great help.

Nat Ersoz
Monday, January 20, 2003

I already understand pointers...but could you please explain how a bank of numbered pidgeonholes works?

Dunno Wair
Monday, January 20, 2003

I don't think a library/card catalog is a very good analogy... both are physically sorted in some way (books into Dewey decimal system, card catalog alphabetical by author or subject, etc.), and inserting a new book or card involves physically moving all the other books/cards (or it would, if librarians didn't thoughfully insert lots of empty shelf space throughout the collection, as a buffer).  Once you get a beginner onto a false analogy like that with a strong concrete image, s/he will be totally up the wrong path.

I like the pigeonhole image much better.

Biotech coder
Wednesday, January 22, 2003

I disagree with whoever said that only C/C++ pointers are a problem.  That may be part of it, but a lot of people simply can't grasp the concept of the extra layer of abstraction.  I took pascal in high school, and most of the class was able to follow along reasonably well until we were introduced to pointers, at which point most of the class was hopelessly lost.

Mike McNertney
Wednesday, January 22, 2003

*  Recent Topics

*  Fog Creek Home