6 ms·

Have you ever come across anything that explains why pointers are hard for some people? I find it difficult to explain pointers to people because I don't under

by ci5er 7y ago

Have you ever come across anything that explains why pointers are hard for some people? I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed. Pointing people to the very elegant treatment of this topic in the old K&R doesn't always do the trick. Somehow.

tomrod 7y ago
I don't think I understand pointers. Maybe we can help each other. My mental model of pointers is a map: lat/long identify the object of interest (the local coffee shop), but not what is interesting about it (their menu and hours).
- jdmichal 7y ago
  To use that analogy: The coordinates tell you where the restaurant is (pointer), but you still have to go to the actual restaurant to get some food (data).
- ci5er 7y ago
  Hmmm. Interesting. I'm going to have to roll that around in my brain for a day-or-so to see if I can make that compute for me. (Which means I may be back here in a day to check back in!) Maybe it's because I started in assembly language, but to me, data exists at an address in memory. Or starting at an address in memory. That data might be on integer, a float, a character, the beginning of a string, the head of an object/data-struct, OR an address of data somewhere else (which may be any of the above again). Pointers, to me, are simply an address of an address of a data thingie. Why would you want to use these? One reason is that pushing large data-objects back-and-forth across function calls is expensive (pointers are usually just 32-bit or 64-bit numbers). Another is that one can have a pool of resources (think polygons in a large 3d scene), that are marked "used" or "unused". This gets a large performance boost from not having to do the whole malloc/free thing on lots and lots of small objects. Another (this is related to the first), the function can receive a data-structure, and modify it (side effects!) without having to copy it and pass the modified copy back. I'm intrigued by your mental model. Having not thought it through - it seems as if lat/long is appropriate, but maybe even the idea that it is a coffee shop that you will find there is undetermined. (That is: the fact that it is a coffee shop is one of the things that is interesting about it, like the menu and hours. Again, I need to think this through). Thanks!
  - kasey_junk 7y ago
    Note that your model is also an abstraction. Modern architectures move data around between a variety of memory locations (and store it in multiple locations) which are all addressed via the pointer ‘transparently’. It’s not really a memory address anymore and hasn’t been for some time. That’s not to say your model is bad, it’s the same one I have in my head. But it’s no more ‘real’ than coordinates or library cards or P.O. Box number.
    - ci5er 7y ago
      Agreed. But it depends on the computer. On the old vectorized machines like the Cray Y-MP, it was always just a mental model. On even modern embedded systems w/o virtual memory, it's pretty close to being really real. (I find that the P.O. Box number thing to be a useful general abstraction for me, but it doesn't seem to convey the concept well to people who are confused. Hence the intent behind the intent of my question: "Does anyone know how to effectively teach pointers?")
    - roelschroeven 7y ago
      Isn't it still the model that is exposed to the programmer, even though internally all kinds of things are going on to make it all go faster? For example, nowadays many/most processors have separate caches for instructions and data, meaning that they strictly speaking don't conform to the Von Neumann architecture. But the programmer doesn't see the different caches, ideally doesn't even see the cache at all. It's like the execution model, where processors do a lot of out-of-order execution, but do a lot of work so they can present a model to the programmer as if everything happens in-order.
      - kasey_junk 7y ago
        That depends on the architecture, the os, the compiler & the runtime. Part of the confusion in teaching pointers (I think) is that we act like they are a lower level abstraction than they are (because they used to be). On modern commodity hardware with mainstream languages pointers have very little to do with memory addresses. Accessing memory via them will not happen in constant time, they may or may not perform better when used, even if the language doesn’t copy them on use the OS or processor might etc. I just find when I try to teach people the memory address model of pointers there are so many exceptions that the model isn’t helpful. Like the OP I struggle with an alternative.
- devnonymous 7y ago
  Hmm, your mental model possibly could use a tweak. Yes, a pointer is like a map. It tells you how to get to the thing but it isn't the thing. It is a reference point, a pointer to the thing. The thing that it points to might be a library, a museum or a place to pick up more maps. Irrespective, the thing to remember is it something to takes you there it is not the place. You may also pass around the map to your friend in effect showing them how to get to the place, without possibly even having seen the place yourself. And if you are a bad person, you could share maps that lead to dead end dumps
- lliamander 7y ago
  When learning abstract programming concepts, I think it is important to have some practice operationalizing that knowledge. Precise definitions are important, but by themselves aren't enough because it doesn't guarantee you'll understand the implications of that definition. Analogies seem like they help, but often lead to error when you reach a point where the analogy is stretched to far. To see if you understand pointers, try exercise #3 here: https://www.joelonsoftware.com/2005/12/29/test-yourself/ https://www.joelonsoftware.com/2005/12/29/test-yourself/ . Just step through the code in your head, and then use your mouse to highlight the text in the box below it. Hopefully that helps you to get started in the right direction.
- cogman10 7y ago
  Do you know what an array is? If so, then you can think of memory like as a giant array of bytes and a pointer as the index in that array. Hurray, you now understand pointers :) Don't muddy it up beyond that.
  - narag 7y ago
    Add to that: you store the index in another cell in the array.
  - burfog 7y ago
    There are different notions of what an array is. In some languages, an array is dynamic. You don't have to declare the size. You can just put stuff at any index you desire, and the array will grow as needed. For example, just set foo[1000000000] to 42. That might take a gigabyte or more of RAM, or just address space, or neither. The indexes might not be required to be numbers. Some languages allow strings or even arbitrary objects as indexes. You could index by a JPEG or a device handle or a float. The values might not be required to have a consistent type. Some languages would let you throw random different-sized things into an array.
    - cogman10 7y ago
      * In some languages, an array is dynamic. Doesn't really matter for the general concept. * The indexes might not be required to be numbers. In most of those languages, that data type is called a map, dictionary, or even associative array. I've seen few languages actually use the phrase "associative array" primarily because it is confusing. But, to be clear, I'm talking about the common "array" definition. That is, a value indexed by a number. * The values might not be required to have a consistent type. Yet, I was clear in saying "a byte array". A pointer points to the byte address and doesn't care about what type is ultimately represented. That is why void pointers are a thing. It is a language level action to reinterpret the pointer into a concrete object type. But again, that confuses the issue of what pointers are with concerns like memory layout and object sizes. To be clear, you don't need to those concepts to understand what a pointer is. * Some languages would let you throw random different-sized things into an array. I specifically said "array of bytes". It does not matter what a language lets you do. A pointer is the head of a byte address and the interpretation of that byte and subsequent bytes are a language level concern. All unneeded information for a discussion on "what is a pointer".
- ChrisSD 7y ago
  I'm semi-convinced the reason many people have a problem understanding pointers is because C makes them needlessly confusing. Or at least in my experience people struggle more with C pointers than they do with learning assembly.
  - jghn 7y ago
    FWIW I struggled with pointers in Pascal before struggling with pointers in C. I do think one area that causes issues with C is any sort of string manipulation requires a reasonable understanding of pointers, and most introductory programming classes tend to focus on things like string manipulation.
- holy_city 7y ago
  A better analogy would be the coffee shop (as a physical building) versus the street address of the building. If you want to do anything in the coffee shop you have to go there, the pointer (address) tells you where to go. And just like real world street addresses, you can't make blind assumptions about pointers. The value may make logical sense, or it may be completely meaningless and you require direction from someone to find it. You can't just write down a random address and expect a building to exist at it. You can hold onto the street address for a coffee shop, put it in a notebook, then one day go to the address to find that the coffee shop was torn down and the street address is invalid.
verall 7y ago
What I see is two types of people, people that understand basic computer architecture and those that don't. The C memory model and pointers come easily to those that understand what a memory address is and how long one is on their favorite architecture. In my experience, people without this knowledge might understand how to use pointers, but not really why they are. And the answer to the "why pointers" question is _not_ "Imagine you want a function that swaps two parameters" nor "because they you would have to copy structs all of the time"
- cogman10 7y ago
  Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. This concept is important not only for how pointers work but even how data is stored on a hard drive. You don't have to go into great detail. All you need to do is say this is a number, it takes n number of bytes to store (Most people who haven't been living under a rock have a knowledge of bytes, just explain it to them using their phone data plan). Draw a picture showing one set of bytes next to another. Write 0x100 at the first set, 0x100 + number of bytes you put in at the second. Then, it is simply "0x100 is what's in a pointer". I don't think that is complex (it shouldn't be). It is intuitive to most. Seeing a picture should solidify things. And finally, it is semi-accurate to how a pointer actually works. Getting into the mud of "A pointer is like a reference in a scholarly paper" or "A pointer is like a link on a webpage" simply confuses what a pointer actually is. And, if that isn't enough, simply write a program using pointers and print out pointer values. It really is a crazy simple concept that doesn't need a whole lot of metaphors. What's worse is when the authors of "what's a pointer" don't know what a pointer is themselves. I've seen that far too often.
  - narag 7y ago
    Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. So is this not how it's explained nowadays? No wonder there's people that doesn't get it. So many concepts, not only about programming, I have learnt in my life first with "this is what happens", then with the precise definition...
grawprog 7y ago
I didn't understand pointers until I understood all variables were all a certain size and stored in a specific place in memory. Which I didn't really understand until I'd been programming for a while.
phailhaus 7y ago
> When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed That's because to them, _everything_ is an "indirect reference". Every time they use a variable it feels like an indirect reference, so what the hell is so special about a pointer? Took me an intro class in computer systems before I could really understand pointers, because nobody wanted to bite the bullet and teach me about the stack. Pointers don't make sense if you don't know that the stack and the heap exist.
- ci5er 7y ago
  > Pointers don't make sense if you don't know that the stack and the heap exist. Now, THAT's interesting...
burfog 7y ago
I've taught pointers to multiple people who struggled. C makes pointers difficult by having some syntax oddities that seem to mainly be intended to save a few characters of source code. The biggest trouble is that C often gives you a free ampersand ("&") when you need one. Consider that p=f and p=&f both can be used to assign the address of a function f to a function pointer p. To a beginner it could look like p takes either type, or that the & really serves no purpose. Consider these four lines of code: char *p1 = "hello"; char a1[] = "hello"; char *p2 = &"hello"; char a2[] = &"hello"; // only this one is junk For the assignment to p1 you get an implied & effectively added into your source code. It may be convenient, but it leads beginners astray with muddled thinking about types. A little-known limitation of C is that you can't really pass arrays to functions. You get that free & again, meaning that you end up passing a pointer. We should need to do printf(&"hello world\n") but that would be inconvenient, so instead we have a language that appears to behave in inconsistent ways. Array dimensionality plays a role here. A real X by Y array, with two dimensions X and Y, can syntactically be used in the same way as an array of pointers to arrays. After being passed to a function, the sizeof operator breaks for both (since now you have just a pointer) but the 2-dimensional nature is lost for only one of the styles. Even the bracket notation is trouble. It is why cute stuff like 4["foo"] can be used to mean 0. That seems harmless enough, but the oddities extend well beyond syntax that nobody should be using. Other issues are pointer arithmetic being surprising and some people being surprised that pointers have types beyond simply "pointer". I find that the best hope for a clear understanding is to constantly remind the student of the above, right from the start. This is slower going, but it prevents serious misunderstandings from persisting and building on each other.
- burfog 7y ago
  Yes, I know about the off-by-one. I can't edit it now. 3["foo"]
- ci5er 7y ago
  So ... the problem with understanding pointers is C syntax? That sounds ... plausible.
nercht12 7y ago
I started to understand pointers easily because I was told variables were mailboxes that held data/stuff (like numbers). A pointer was just another variable (mailbox) that held the address of a different mailbox. There you have it. Pointers in two sentences. The "indirect reference" yada yada is too technical, requiring your audience to already understand those terms. It also ends up leading to cyclical definitions if you try going too much into detail (because data structures can hold pointers).
Ace17 7y ago
> I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. Maybe they don't know what they are missing. When I was learning C two decades ago, my first thought was that pointers were solving no real problems, and that I will be able to do without them. Then I had to implement the "swap" function.

by ci5er 7y ago

tomrod 7y ago

I don't think I understand pointers. Maybe we can help each other. My mental model of pointers is a map: lat/long identify the object of interest (the local coffee shop), but not what is interesting about it (their menu and hours).

jdmichal 7y ago
To use that analogy: The coordinates tell you where the restaurant is (pointer), but you still have to go to the actual restaurant to get some food (data).
ci5er 7y ago
Hmmm. Interesting. I'm going to have to roll that around in my brain for a day-or-so to see if I can make that compute for me. (Which means I may be back here in a day to check back in!) Maybe it's because I started in assembly language, but to me, data exists at an address in memory. Or starting at an address in memory. That data might be on integer, a float, a character, the beginning of a string, the head of an object/data-struct, OR an address of data somewhere else (which may be any of the above again). Pointers, to me, are simply an address of an address of a data thingie. Why would you want to use these? One reason is that pushing large data-objects back-and-forth across function calls is expensive (pointers are usually just 32-bit or 64-bit numbers). Another is that one can have a pool of resources (think polygons in a large 3d scene), that are marked "used" or "unused". This gets a large performance boost from not having to do the whole malloc/free thing on lots and lots of small objects. Another (this is related to the first), the function can receive a data-structure, and modify it (side effects!) without having to copy it and pass the modified copy back. I'm intrigued by your mental model. Having not thought it through - it seems as if lat/long is appropriate, but maybe even the idea that it is a coffee shop that you will find there is undetermined. (That is: the fact that it is a coffee shop is one of the things that is interesting about it, like the menu and hours. Again, I need to think this through). Thanks!
- kasey_junk 7y ago
  Note that your model is also an abstraction. Modern architectures move data around between a variety of memory locations (and store it in multiple locations) which are all addressed via the pointer ‘transparently’. It’s not really a memory address anymore and hasn’t been for some time. That’s not to say your model is bad, it’s the same one I have in my head. But it’s no more ‘real’ than coordinates or library cards or P.O. Box number.
  - ci5er 7y ago
    Agreed. But it depends on the computer. On the old vectorized machines like the Cray Y-MP, it was always just a mental model. On even modern embedded systems w/o virtual memory, it's pretty close to being really real. (I find that the P.O. Box number thing to be a useful general abstraction for me, but it doesn't seem to convey the concept well to people who are confused. Hence the intent behind the intent of my question: "Does anyone know how to effectively teach pointers?")
  - roelschroeven 7y ago
    Isn't it still the model that is exposed to the programmer, even though internally all kinds of things are going on to make it all go faster? For example, nowadays many/most processors have separate caches for instructions and data, meaning that they strictly speaking don't conform to the Von Neumann architecture. But the programmer doesn't see the different caches, ideally doesn't even see the cache at all. It's like the execution model, where processors do a lot of out-of-order execution, but do a lot of work so they can present a model to the programmer as if everything happens in-order.
    - kasey_junk 7y ago
      That depends on the architecture, the os, the compiler & the runtime. Part of the confusion in teaching pointers (I think) is that we act like they are a lower level abstraction than they are (because they used to be). On modern commodity hardware with mainstream languages pointers have very little to do with memory addresses. Accessing memory via them will not happen in constant time, they may or may not perform better when used, even if the language doesn’t copy them on use the OS or processor might etc. I just find when I try to teach people the memory address model of pointers there are so many exceptions that the model isn’t helpful. Like the OP I struggle with an alternative.
devnonymous 7y ago
Hmm, your mental model possibly could use a tweak. Yes, a pointer is like a map. It tells you how to get to the thing but it isn't the thing. It is a reference point, a pointer to the thing. The thing that it points to might be a library, a museum or a place to pick up more maps. Irrespective, the thing to remember is it something to takes you there it is not the place. You may also pass around the map to your friend in effect showing them how to get to the place, without possibly even having seen the place yourself. And if you are a bad person, you could share maps that lead to dead end dumps
lliamander 7y ago
When learning abstract programming concepts, I think it is important to have some practice operationalizing that knowledge. Precise definitions are important, but by themselves aren't enough because it doesn't guarantee you'll understand the implications of that definition. Analogies seem like they help, but often lead to error when you reach a point where the analogy is stretched to far. To see if you understand pointers, try exercise #3 here: https://www.joelonsoftware.com/2005/12/29/test-yourself/ https://www.joelonsoftware.com/2005/12/29/test-yourself/ . Just step through the code in your head, and then use your mouse to highlight the text in the box below it. Hopefully that helps you to get started in the right direction.
cogman10 7y ago
Do you know what an array is? If so, then you can think of memory like as a giant array of bytes and a pointer as the index in that array. Hurray, you now understand pointers :) Don't muddy it up beyond that.
- narag 7y ago
  Add to that: you store the index in another cell in the array.
- burfog 7y ago
  There are different notions of what an array is. In some languages, an array is dynamic. You don't have to declare the size. You can just put stuff at any index you desire, and the array will grow as needed. For example, just set foo[1000000000] to 42. That might take a gigabyte or more of RAM, or just address space, or neither. The indexes might not be required to be numbers. Some languages allow strings or even arbitrary objects as indexes. You could index by a JPEG or a device handle or a float. The values might not be required to have a consistent type. Some languages would let you throw random different-sized things into an array.
  - cogman10 7y ago
    * In some languages, an array is dynamic. Doesn't really matter for the general concept. * The indexes might not be required to be numbers. In most of those languages, that data type is called a map, dictionary, or even associative array. I've seen few languages actually use the phrase "associative array" primarily because it is confusing. But, to be clear, I'm talking about the common "array" definition. That is, a value indexed by a number. * The values might not be required to have a consistent type. Yet, I was clear in saying "a byte array". A pointer points to the byte address and doesn't care about what type is ultimately represented. That is why void pointers are a thing. It is a language level action to reinterpret the pointer into a concrete object type. But again, that confuses the issue of what pointers are with concerns like memory layout and object sizes. To be clear, you don't need to those concepts to understand what a pointer is. * Some languages would let you throw random different-sized things into an array. I specifically said "array of bytes". It does not matter what a language lets you do. A pointer is the head of a byte address and the interpretation of that byte and subsequent bytes are a language level concern. All unneeded information for a discussion on "what is a pointer".
ChrisSD 7y ago
I'm semi-convinced the reason many people have a problem understanding pointers is because C makes them needlessly confusing. Or at least in my experience people struggle more with C pointers than they do with learning assembly.
- jghn 7y ago
  FWIW I struggled with pointers in Pascal before struggling with pointers in C. I do think one area that causes issues with C is any sort of string manipulation requires a reasonable understanding of pointers, and most introductory programming classes tend to focus on things like string manipulation.
holy_city 7y ago
A better analogy would be the coffee shop (as a physical building) versus the street address of the building. If you want to do anything in the coffee shop you have to go there, the pointer (address) tells you where to go. And just like real world street addresses, you can't make blind assumptions about pointers. The value may make logical sense, or it may be completely meaningless and you require direction from someone to find it. You can't just write down a random address and expect a building to exist at it. You can hold onto the street address for a coffee shop, put it in a notebook, then one day go to the address to find that the coffee shop was torn down and the street address is invalid.

verall 7y ago

What I see is two types of people, people that understand basic computer architecture and those that don't. The C memory model and pointers come easily to those that understand what a memory address is and how long one is on their favorite architecture. In my experience, people without this knowledge might understand how to use pointers, but not really why they are. And the answer to the "why pointers" question is _not_ "Imagine you want a function that swaps two parameters" nor "because they you would have to copy structs all of the time"

cogman10 7y ago
Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. This concept is important not only for how pointers work but even how data is stored on a hard drive. You don't have to go into great detail. All you need to do is say this is a number, it takes n number of bytes to store (Most people who haven't been living under a rock have a knowledge of bytes, just explain it to them using their phone data plan). Draw a picture showing one set of bytes next to another. Write 0x100 at the first set, 0x100 + number of bytes you put in at the second. Then, it is simply "0x100 is what's in a pointer". I don't think that is complex (it shouldn't be). It is intuitive to most. Seeing a picture should solidify things. And finally, it is semi-accurate to how a pointer actually works. Getting into the mud of "A pointer is like a reference in a scholarly paper" or "A pointer is like a link on a webpage" simply confuses what a pointer actually is. And, if that isn't enough, simply write a program using pointers and print out pointer values. It really is a crazy simple concept that doesn't need a whole lot of metaphors. What's worse is when the authors of "what's a pointer" don't know what a pointer is themselves. I've seen that far too often.
- narag 7y ago
  Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. So is this not how it's explained nowadays? No wonder there's people that doesn't get it. So many concepts, not only about programming, I have learnt in my life first with "this is what happens", then with the precise definition...

grawprog 7y ago

I didn't understand pointers until I understood all variables were all a certain size and stored in a specific place in memory. Which I didn't really understand until I'd been programming for a while.

phailhaus 7y ago

> When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed That's because to them, _everything_ is an "indirect reference". Every time they use a variable it feels like an indirect reference, so what the hell is so special about a pointer? Took me an intro class in computer systems before I could really understand pointers, because nobody wanted to bite the bullet and teach me about the stack. Pointers don't make sense if you don't know that the stack and the heap exist.

ci5er 7y ago
> Pointers don't make sense if you don't know that the stack and the heap exist. Now, THAT's interesting...

burfog 7y ago

I've taught pointers to multiple people who struggled. C makes pointers difficult by having some syntax oddities that seem to mainly be intended to save a few characters of source code. The biggest trouble is that C often gives you a free ampersand ("&") when you need one. Consider that p=f and p=&f both can be used to assign the address of a function f to a function pointer p. To a beginner it could look like p takes either type, or that the & really serves no purpose. Consider these four lines of code: char *p1 = "hello"; char a1[] = "hello"; char *p2 = &"hello"; char a2[] = &"hello"; // only this one is junk For the assignment to p1 you get an implied & effectively added into your source code. It may be convenient, but it leads beginners astray with muddled thinking about types. A little-known limitation of C is that you can't really pass arrays to functions. You get that free & again, meaning that you end up passing a pointer. We should need to do printf(&"hello world\n") but that would be inconvenient, so instead we have a language that appears to behave in inconsistent ways. Array dimensionality plays a role here. A real X by Y array, with two dimensions X and Y, can syntactically be used in the same way as an array of pointers to arrays. After being passed to a function, the sizeof operator breaks for both (since now you have just a pointer) but the 2-dimensional nature is lost for only one of the styles. Even the bracket notation is trouble. It is why cute stuff like 4["foo"] can be used to mean 0. That seems harmless enough, but the oddities extend well beyond syntax that nobody should be using. Other issues are pointer arithmetic being surprising and some people being surprised that pointers have types beyond simply "pointer". I find that the best hope for a clear understanding is to constantly remind the student of the above, right from the start. This is slower going, but it prevents serious misunderstandings from persisting and building on each other.

burfog 7y ago
Yes, I know about the off-by-one. I can't edit it now. 3["foo"]
ci5er 7y ago
So ... the problem with understanding pointers is C syntax? That sounds ... plausible.

nercht12 7y ago

I started to understand pointers easily because I was told variables were mailboxes that held data/stuff (like numbers). A pointer was just another variable (mailbox) that held the address of a different mailbox. There you have it. Pointers in two sentences. The "indirect reference" yada yada is too technical, requiring your audience to already understand those terms. It also ends up leading to cyclical definitions if you try going too much into detail (because data structures can hold pointers).

Ace17 7y ago

> I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. Maybe they don't know what they are missing. When I was learning C two decades ago, my first thought was that pointers were solving no real problems, and that I will be able to do without them. Then I had to implement the "swap" function.