5 ms·

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for

by aphrax 5y ago

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for me... Edit: poor grammar

sanedigital 5y ago
One analogy I’ve used to teach pointers is to think of them as phone numbers. They’re an identifier used to get ahold of something that you might not otherwise know exactly where it is. If you call my number, I’ll pick up. But if I transfer my number to someone else, that doesn’t mean anything happened to me personally. That number is just not pointing to new anymore.
unwind 5y ago
That is fascinating, thanks for sharing. What part of pointers is it that makes it so hard for you to grasp, if you have any thoughts? Do you have any experience in other programming languages? How familiar are you with low-level computer architecture, at the CPU/memory level? I guess one important part is to realize that in C, variables are basically names for memory locations, that in turn hold values. In other languages variables can be more abstract, and you have no idea how the value(s) are being associated with the variable name. I started writing an example here, but I ran out of time and it wasn't good enough. :) Sorry. EDIT: Now I've taken a loo at the relevant pages in the guide itself, and it seemed to explain the concepts very clearly and easily, so ... I'm not sure how to help. :)
- aphrax 5y ago
  Thanks for this - I think you are on to something when you mention the low level architecture, on reflection this is where I need to fully understand the concepts - I'm messing around in this area with the usual (Nand to Tetris) type info/tutorials. I'll then come back to this manual I'm sure. Like I say - I've enjoyed it quite a bit. Its certainly me lacking - not the book!
  - argvargc 5y ago
    Something that might help is understanding a very fundamental thing about computers: they are very, very stupid. Essentially, they don't/can't know anything about anything, at the most fundamental levels of their construction, and have to be hand-held every tiny step of the way. A computer is essentially a highly complex arrangement of on/off switches - there's little else fundamentally in there doing anything at all other than something causing the first switch to cycle between on and off states and cascade to all the rest (this isn't entirely accurate but it's close enough to make te point). This gives rise to situations where in order to create greater levels of complexity, lots of unintuitive, and seemingly even pointless things need to be done. For example: assigning letterbox addresses to every discrete portion of memory. Then things like "I want to read the values from this part of memory up to this part" require laboriously adding 1 to a value (a pointer) that tracks which address the computer is currently "thinking" about. It's so stupid it needs to remember where it is all the time like this, or it can't do anything. Because C is very close to this mundane and laborious fundamental architecture, it (usefully in that case) deals with concepts like "pointers". In languages at just a bit higher level, the language internals deal with pointers so that we as programmers don't have to.
  - dave84 5y ago
    One tool I use with my own students to visually demonstrate C pointer code is CTutor from PythonTutor. http://pythontutor.com/c.html#mode=edit http://pythontutor.com/c.html#mode=edit If you click down to the bottom and choose from the examples "Pointer Levels" you'll get a good idea of the tools powers.
sedeki 5y ago
Try to explain where you're stuck.
redis_mlc 5y ago
Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) https://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628 https://www.amazon.com/Programming-Language-2nd-Brian-Kernig... Also, there's nothing magical about pointers - scripting languages use "handles", which is the same thing except they're read-only to the end-user programmer. The real challenge with C is multi-threaded programming, so don't do that if you don't need it.
- dvfjsdhgfv 5y ago
  > Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) This is really an amazing feat: books on programming languages age really fast. This one - not so much. And you can really appreciate the careful thought that was put in each sentence. Peerless. > The real challenge with C is multi-threaded programming, so don't do that if you don't need it. Well, these days it's harder and harder to avoid it if you want to write efficient apps - we got more cores and the clocks remain more or less the same.
  - redis_mlc 5y ago
    > Well, these days it's harder and harder to avoid it if you want to write efficient apps - we got more cores and the clocks remain more or less the same. There was some article a few years ago that said the apps they looked at didn't actually run faster after making some routines parallel, so it depends, and you will definitely have more debugging to do.
- cassepipe 5y ago
  Personnally I have learned C following the CS50 course on Harvard's youtube channel and pointer came easily with http://alumni.cs.ucr.edu/~pdiloren/C++_Pointers/ http://alumni.cs.ucr.edu/~pdiloren/C++_Pointers/. It's a great (free as in beer) start.
- beej71 5y ago
  I agree. If you're only going to read one book, that's the book. :-)
bluetomcat 5y ago
Just another integral data type which supports not only arithmetic (adding or removing an integral value), but also "dereferencing" which means getting a value of the pointed-to type at the pointed-to address. The quantities added or removed in arithmetic operations are the same as the size of the type that is being pointed to.
- shric 5y ago
  It's incorrect to call a pointer an integral type. It doesn't behave like an integer (you can't add two pointers together). You can't even subtract two pointers from each other unless they point into the same array (or one element past) without causing undefined behaviour. You can't even reliably convert a pointer generally to an integer and back again unless it's a void *. Edit: just remembered I wrote a rambling on this in 2014: https://ramblings.implicit.net/c/2014/04/21/pointers-are-not-integers.html https://ramblings.implicit.net/c/2014/04/21/pointers-are-not...
  - bluetomcat 5y ago
    Strictly it's not an integral type as you point out, but for the purpose of introducing a beginner who might be afraid that there is "deep magic" involved, it can be a helpful comparison. Subtracting two pointers yields ptrdiff_t which is not a pointer type in itself.
    - shric 5y ago
      Pretending it's an integral type leads to all sorts of conceptual mistakes, imho. It has almost no comparable semantics to integers.
1_player 5y ago
A pointer is a level of indirection. A regular variable is a place in RAM that contains a certain value. A pointer is a variable whose value is the address of another variable. X = 5 Y = location in memory of X Now you can use Y to manipulate X
DyslexicAtheist 5y ago
around 25 years ago I got so frustrated because I hit the same brick walls over and over especially with advanced pointer stuff. It sounds silly today but what helped me are some really basic books about C. iirc the "for dummies" series and others. It took another couple of years until I understood what I lacked wasn't time spent reading another section on pointers but additional tooling. Using a debugger and stepping through programs was the next breakthrough. Looking back today understanding my C (on UNIX) isn't just the language it's a whole ecosystem of tools to measure what is going on and manipulating state so that I can troubleshoot. After gdb came valgrind, strace, lsof, signal handling (kill), process control, gcov, the appropriate type of CFLAGS to use (e.g. the compiler itself) and how to stay sane using Make. None of them have to do with pointers but they make life a lot easier. To become productive at this takes years but becoming good took me decades. C (imho) isn't just another language but a complete career path with dozens of branches into other areas. If you stay patient with yourself and treat it as a journey instead of a milestone it can deepen your understanding of systems (nod to eBPF) in situations many others will bail out long before. Don't give up and then not much will look scary any more.
- aphrax 5y ago
  Thanks so much for this reply, really quite inspiring. Much appreciated.
- agumonkey 5y ago
  Ability to inspect is vital indeed
quelsolaar 5y ago
Try watching this: https://youtu.be/443UNeGrFoM https://youtu.be/443UNeGrFoM Its long and is filled with other stuff about C programming but it goes in to dept about how to think about pointers. Good Luck!
Koshkin 5y ago
1) A pointer is a memory address of an object. 2) Pointer arithmetic takes into account the size of the type pointed to. 3) The asterisk operator gives you access to the object. 4) The ampersand operator gives you the pointer to the object. If you understand this, you understand pointers. (The arrow operator is syntactic sugar.)
squarefoot 5y ago
Pointers are easy and fun, just keep experimenting with them. What is essential is understanding that they're nothing more than like a piece of paper containing where something is instead of being part of that something, and they're the same size of the address registers of the underlying hardware as they must be able to point everywhere in the addressable memory. Therefore, on a 32 bit system pointers will be 32 bits long, on a 64 bit system they will be 64 bits long, etc. no matter what they point to. That is, both a pointer to a single byte and a pointer to a 10GB memory chunk will be of the same size because they just hold a memory location whose value represents where that data starts. Therefore, declaring pointers to a certain type doesn't change their size at all, it just becomes handy when one needs to go back and forth in a memory area in which objects of that type are stored one after another, so that incrementing or decrementing the pointer by a number actually means that number times the size of the objects. Imagine asking for directions to someone and he replies "3rd door" or "3rd building" or "3rd block"; he gave you a pointer that is always the same size, but how much you have to walk will depend on the destination (size). Once grasped the above, it should become a lot more easy; I had the same problems, then one day had a flash and they became totally clear (and fun). It may be of help experimenting with a debugger, or simply printf-ing all values a pointer assumes when declared, assigned, incremented/decremented etc. Keep also track of the pointed data values, changing it instead of the pointer, or the other way around, are common mistakes. An old small command line program like "cdecl" can help a lot to understand complex declarations, and someone has even made an interactive webpage around it (cdecl.org). example: cdecl> explain char ((x())[]) () declare x as function returning pointer to array of pointer to function returning char

by aphrax 5y ago

I've enjoyed this guide a number of times but each time I hit a brick wall trying to understand pointers. I'm still keen to learn but it just doesnt 'click' for me... Edit: poor grammar

sanedigital 5y ago

One analogy I’ve used to teach pointers is to think of them as phone numbers. They’re an identifier used to get ahold of something that you might not otherwise know exactly where it is. If you call my number, I’ll pick up. But if I transfer my number to someone else, that doesn’t mean anything happened to me personally. That number is just not pointing to new anymore.

unwind 5y ago

That is fascinating, thanks for sharing. What part of pointers is it that makes it so hard for you to grasp, if you have any thoughts? Do you have any experience in other programming languages? How familiar are you with low-level computer architecture, at the CPU/memory level? I guess one important part is to realize that in C, variables are basically names for memory locations, that in turn hold values. In other languages variables can be more abstract, and you have no idea how the value(s) are being associated with the variable name. I started writing an example here, but I ran out of time and it wasn't good enough. :) Sorry. EDIT: Now I've taken a loo at the relevant pages in the guide itself, and it seemed to explain the concepts very clearly and easily, so ... I'm not sure how to help. :)

aphrax 5y ago
Thanks for this - I think you are on to something when you mention the low level architecture, on reflection this is where I need to fully understand the concepts - I'm messing around in this area with the usual (Nand to Tetris) type info/tutorials. I'll then come back to this manual I'm sure. Like I say - I've enjoyed it quite a bit. Its certainly me lacking - not the book!
- argvargc 5y ago
  Something that might help is understanding a very fundamental thing about computers: they are very, very stupid. Essentially, they don't/can't know anything about anything, at the most fundamental levels of their construction, and have to be hand-held every tiny step of the way. A computer is essentially a highly complex arrangement of on/off switches - there's little else fundamentally in there doing anything at all other than something causing the first switch to cycle between on and off states and cascade to all the rest (this isn't entirely accurate but it's close enough to make te point). This gives rise to situations where in order to create greater levels of complexity, lots of unintuitive, and seemingly even pointless things need to be done. For example: assigning letterbox addresses to every discrete portion of memory. Then things like "I want to read the values from this part of memory up to this part" require laboriously adding 1 to a value (a pointer) that tracks which address the computer is currently "thinking" about. It's so stupid it needs to remember where it is all the time like this, or it can't do anything. Because C is very close to this mundane and laborious fundamental architecture, it (usefully in that case) deals with concepts like "pointers". In languages at just a bit higher level, the language internals deal with pointers so that we as programmers don't have to.
- dave84 5y ago
  One tool I use with my own students to visually demonstrate C pointer code is CTutor from PythonTutor. http://pythontutor.com/c.html#mode=edit http://pythontutor.com/c.html#mode=edit If you click down to the bottom and choose from the examples "Pointer Levels" you'll get a good idea of the tools powers.

sedeki 5y ago

Try to explain where you're stuck.

redis_mlc 5y ago

Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) https://www.amazon.com/Programming-Language-2nd-Brian-Kernighan/dp/0131103628 https://www.amazon.com/Programming-Language-2nd-Brian-Kernig... Also, there's nothing magical about pointers - scripting languages use "handles", which is the same thing except they're read-only to the end-user programmer. The real challenge with C is multi-threaded programming, so don't do that if you don't need it.

dvfjsdhgfv 5y ago
> Just learn C by reading and working through the K&R book. (It's one of the best CS books ever written.) This is really an amazing feat: books on programming languages age really fast. This one - not so much. And you can really appreciate the careful thought that was put in each sentence. Peerless. > The real challenge with C is multi-threaded programming, so don't do that if you don't need it. Well, these days it's harder and harder to avoid it if you want to write efficient apps - we got more cores and the clocks remain more or less the same.
- redis_mlc 5y ago
  > Well, these days it's harder and harder to avoid it if you want to write efficient apps - we got more cores and the clocks remain more or less the same. There was some article a few years ago that said the apps they looked at didn't actually run faster after making some routines parallel, so it depends, and you will definitely have more debugging to do.
cassepipe 5y ago
Personnally I have learned C following the CS50 course on Harvard's youtube channel and pointer came easily with http://alumni.cs.ucr.edu/~pdiloren/C++_Pointers/ http://alumni.cs.ucr.edu/~pdiloren/C++_Pointers/. It's a great (free as in beer) start.
beej71 5y ago
I agree. If you're only going to read one book, that's the book. :-)

bluetomcat 5y ago

Just another integral data type which supports not only arithmetic (adding or removing an integral value), but also "dereferencing" which means getting a value of the pointed-to type at the pointed-to address. The quantities added or removed in arithmetic operations are the same as the size of the type that is being pointed to.

shric 5y ago
It's incorrect to call a pointer an integral type. It doesn't behave like an integer (you can't add two pointers together). You can't even subtract two pointers from each other unless they point into the same array (or one element past) without causing undefined behaviour. You can't even reliably convert a pointer generally to an integer and back again unless it's a void *. Edit: just remembered I wrote a rambling on this in 2014: https://ramblings.implicit.net/c/2014/04/21/pointers-are-not-integers.html https://ramblings.implicit.net/c/2014/04/21/pointers-are-not...
- bluetomcat 5y ago
  Strictly it's not an integral type as you point out, but for the purpose of introducing a beginner who might be afraid that there is "deep magic" involved, it can be a helpful comparison. Subtracting two pointers yields ptrdiff_t which is not a pointer type in itself.
  - shric 5y ago
    Pretending it's an integral type leads to all sorts of conceptual mistakes, imho. It has almost no comparable semantics to integers.

1_player 5y ago

A pointer is a level of indirection. A regular variable is a place in RAM that contains a certain value. A pointer is a variable whose value is the address of another variable. X = 5 Y = location in memory of X Now you can use Y to manipulate X

DyslexicAtheist 5y ago

around 25 years ago I got so frustrated because I hit the same brick walls over and over especially with advanced pointer stuff. It sounds silly today but what helped me are some really basic books about C. iirc the "for dummies" series and others. It took another couple of years until I understood what I lacked wasn't time spent reading another section on pointers but additional tooling. Using a debugger and stepping through programs was the next breakthrough. Looking back today understanding my C (on UNIX) isn't just the language it's a whole ecosystem of tools to measure what is going on and manipulating state so that I can troubleshoot. After gdb came valgrind, strace, lsof, signal handling (kill), process control, gcov, the appropriate type of CFLAGS to use (e.g. the compiler itself) and how to stay sane using Make. None of them have to do with pointers but they make life a lot easier. To become productive at this takes years but becoming good took me decades. C (imho) isn't just another language but a complete career path with dozens of branches into other areas. If you stay patient with yourself and treat it as a journey instead of a milestone it can deepen your understanding of systems (nod to eBPF) in situations many others will bail out long before. Don't give up and then not much will look scary any more.

aphrax 5y ago
Thanks so much for this reply, really quite inspiring. Much appreciated.
agumonkey 5y ago
Ability to inspect is vital indeed

quelsolaar 5y ago

Try watching this: https://youtu.be/443UNeGrFoM https://youtu.be/443UNeGrFoM Its long and is filled with other stuff about C programming but it goes in to dept about how to think about pointers. Good Luck!

Koshkin 5y ago

1) A pointer is a memory address of an object. 2) Pointer arithmetic takes into account the size of the type pointed to. 3) The asterisk operator gives you access to the object. 4) The ampersand operator gives you the pointer to the object. If you understand this, you understand pointers. (The arrow operator is syntactic sugar.)

squarefoot 5y ago

Pointers are easy and fun, just keep experimenting with them. What is essential is understanding that they're nothing more than like a piece of paper containing where something is instead of being part of that something, and they're the same size of the address registers of the underlying hardware as they must be able to point everywhere in the addressable memory. Therefore, on a 32 bit system pointers will be 32 bits long, on a 64 bit system they will be 64 bits long, etc. no matter what they point to. That is, both a pointer to a single byte and a pointer to a 10GB memory chunk will be of the same size because they just hold a memory location whose value represents where that data starts. Therefore, declaring pointers to a certain type doesn't change their size at all, it just becomes handy when one needs to go back and forth in a memory area in which objects of that type are stored one after another, so that incrementing or decrementing the pointer by a number actually means that number times the size of the objects. Imagine asking for directions to someone and he replies "3rd door" or "3rd building" or "3rd block"; he gave you a pointer that is always the same size, but how much you have to walk will depend on the destination (size). Once grasped the above, it should become a lot more easy; I had the same problems, then one day had a flash and they became totally clear (and fun). It may be of help experimenting with a debugger, or simply printf-ing all values a pointer assumes when declared, assigned, incremented/decremented etc. Keep also track of the pointed data values, changing it instead of the pointer, or the other way around, are common mistakes. An old small command line program like "cdecl" can help a lot to understand complex declarations, and someone has even made an interactive webpage around it (cdecl.org). example: cdecl> explain char ((x())[]) () declare x as function returning pointer to array of pointer to function returning char