6 ms·

This article and most of the comments here are just over complicating a straightforward idea. I simply don't get why people always think "pointers" are difficul

This article and most of the comments here are just over complicating a straightforward idea. I simply don't get why people always think "pointers" are difficult to understand; it is manipulating them to do advanced stuff that gets tricky. But nevertheless it gets easier with time and experience since you start picking up on the common idioms. For anybody beginning C, my advice is to not make an "imaginary dragon" out of "pointers" but just study examples and write your own programs using them and soon they will seem "obvious".

globular-toast 6y ago
I agree. I really can't understand what is complicated about them. I find the same with programmers who find the DAG in git difficult to grasp. It's just linking stuff together. It's how the the web works. It's how linked lists work. What's difficult about it. I think exposure to assembly demystifies all of this stuff about C. Most of C is just making stuff really convenient that you would do anyway in assembly. A pointer is just a memory address, but in C it also has a type. The only thing the type is for is so the compiler knows how many bytes to add/subtract when you increment/decrement the pointer. That's it. In assembly you'd just have to remember how many bytes to increment/decrement yourself. Reading Knuth also helps with this. It's one of the reasons he uses a synthetic assembly language rather than a high-level language. There are no pointers. There is just memory, and you need some way to find stuff in memory, otherwise it is just noise.
- dnautics 6y ago
  IMO I don't think the problem in C is pointers, it's that pointers are arrays, in the sense that they are syntactic sugar. This is incredibly confusing, and probably part of the reason why most modern systems languages wisely make arrays more e.g. {pointer, length}, sometimes introduce slices, where length is runtime, and make you do some syntactic work to pull out the pointer from the array.
  - kevin_thibedeau 6y ago
    Pointers aren't arrays because sizeof works differently and pointer arithmetic on a pointer-to-array doesn't work "right". The more confusing part is the variety of ways pointers get used: allocated memory, opaque object handles, extra return values, modifiable input values, array indexing, function pointers, etc.
  - coliveira 6y ago
    No, pointers are not arrays. Pointers can point to arrays and, because of the language rules, you can do pretty much anything you can do to an array through pointers, but they are definitively not arrays.
    - dnautics 6y ago
      I think we see the problem here. I've been using C on and off (granted, never formally educated in it) for 20 years now and I don't know the difference.
      - coliveira 6y ago
        An array is a variable that is declared to contain sequential data (using square brackets and the desired number of elements). It is immutable. A pointer is a mutable variable that can be made to point to anything, and it can be used to reference an array or any of its elements. These are different concepts, although the language allows a lot of operations in common between them.
        dnautics 6y ago
        I see. I mean, yes I obviously know the difference between pointers and arrays as general CS concepts (and articulated how other languages get it correct), but we're not talking about CS, we're talking about C. Perhaps I should have said in my original context, "array syntax" is the same as "pointer syntax". But while the CS concepts of "array" and "pointer" are indeed different, the C syntax elides the two. C does not track the immutable length of the array for you.
- wnissen 6y ago
  Pointers are super hard if you've not dealt with indirection before. Especially in C/C++ when you can dereference pretty much anything and you get a runtime segfault with no other diagnostic. Do you not remember when that was mystifying? Given that a huge fraction of vulnerabilities are unsafe memory accesses, I think most people still make plenty of mistakes around pointers. The analogy I like is the address of IHOP (International House of Pancakes). If I know the address of IHOP is 4567 Portobello Rd., why don't I have pancakes?!? It's the same with a pointer. Similarly, if I have a pancake, and someone calls and asks me for the address of IHOP, it's also wrong to bring the pancake to them in lieu of the address.
spaetzleesser 6y ago
Same here. After I read K&R C's memory model seemed pretty simple and straightforward. Whenever I have trouble figuring out something I usually draw a little diagram with the memory space, where things are allocated and how handles and pointers relate to the memory space.
michaelbrave 6y ago
When I got started I found the syntax of it confusing, like why doesn't de-referencing look more distinct kind of thing. I got used to it eventually but it didn't feel very clear at first.
Corazoor 6y ago
I could read and write commodore 128 assembler before I started to learn C, so I knew about adresses, adressing modes and how to use them. Despite that, I still had trouble wrapping my head around the concept of pointers at first. There are multiple things that can make it confusing, and they kinda collude to make it harder to get. In order to understand them at all, you have to know - what a variable represents (a region of memory) - what an adress/reference is (the index of said region in memory) - how a value is stored in and read from said variable (by putting it into or reading from the memory beginnen at this adress) - that you actually can treat an adress as a value, i.e store it in another variable Thats already four deeply related, but still different things you have to wrap your head around. To make matters worse, the way pointers often are used (and most of the time introduced), is to point to another variable. Now you have two adresses, and two values, one of wich is one of the adresses. If that sentence confuses you, that is how beginners feel about it as well! Dereferencing is not straightforward either: It makes a pointer behave as if it were the pointed to variable, which in the usual introductory toy examples makes it look like a totally unnecessary and useless operation. Also the size of the pointed to variable is encoded via the pointers type, and does not have to match the size of the actually pointed to thing. Another mindblower that one. Lastly there is the linguistic problem that we tend to say a variable IS its value. Which is actually misleading in multiple ways if a variable contains the adress of another one. Ultimately I had to understand what pointers are NOT, in order to finally grasp what they are.
- pjmlp 6y ago
  Did the 128 Assembler not support declaring variables? I was already using variables, arrays and structs on MS-DOS/Amiga macro Assemblers.
  - Corazoor 6y ago
    While there were macro assemblers, all I did use was the built-in machine monitor, which was basically a system provided debugger. But you could assemble single mnemonics into a memory location of your choosing, so I would put programs together directly in memory, one instruction at a time. That required counting their length as well, and doesn't support any constructs that span multiple instructions, like macros or variables... I knew variables already from commodore Basic, which i learned first. But there was no concept of pointers, direct interaction with memory happened via peek and poke, and the adress space was so small, you just chose an adress where to put your stuff and worked with offsets. It is worth remembering that on these old machines there was no OS managed memory allocation... So there was much less need to work with adresses unknown at "compile time".

globular-toast 6y ago

I agree. I really can't understand what is complicated about them. I find the same with programmers who find the DAG in git difficult to grasp. It's just linking stuff together. It's how the the web works. It's how linked lists work. What's difficult about it. I think exposure to assembly demystifies all of this stuff about C. Most of C is just making stuff really convenient that you would do anyway in assembly. A pointer is just a memory address, but in C it also has a type. The only thing the type is for is so the compiler knows how many bytes to add/subtract when you increment/decrement the pointer. That's it. In assembly you'd just have to remember how many bytes to increment/decrement yourself. Reading Knuth also helps with this. It's one of the reasons he uses a synthetic assembly language rather than a high-level language. There are no pointers. There is just memory, and you need some way to find stuff in memory, otherwise it is just noise.

dnautics 6y ago
IMO I don't think the problem in C is pointers, it's that pointers are arrays, in the sense that they are syntactic sugar. This is incredibly confusing, and probably part of the reason why most modern systems languages wisely make arrays more e.g. {pointer, length}, sometimes introduce slices, where length is runtime, and make you do some syntactic work to pull out the pointer from the array.
- kevin_thibedeau 6y ago
  Pointers aren't arrays because sizeof works differently and pointer arithmetic on a pointer-to-array doesn't work "right". The more confusing part is the variety of ways pointers get used: allocated memory, opaque object handles, extra return values, modifiable input values, array indexing, function pointers, etc.
- coliveira 6y ago
  No, pointers are not arrays. Pointers can point to arrays and, because of the language rules, you can do pretty much anything you can do to an array through pointers, but they are definitively not arrays.
  - dnautics 6y ago
    I think we see the problem here. I've been using C on and off (granted, never formally educated in it) for 20 years now and I don't know the difference.
    - coliveira 6y ago
      An array is a variable that is declared to contain sequential data (using square brackets and the desired number of elements). It is immutable. A pointer is a mutable variable that can be made to point to anything, and it can be used to reference an array or any of its elements. These are different concepts, although the language allows a lot of operations in common between them.
      - dnautics 6y ago
        I see. I mean, yes I obviously know the difference between pointers and arrays as general CS concepts (and articulated how other languages get it correct), but we're not talking about CS, we're talking about C. Perhaps I should have said in my original context, "array syntax" is the same as "pointer syntax". But while the CS concepts of "array" and "pointer" are indeed different, the C syntax elides the two. C does not track the immutable length of the array for you.
wnissen 6y ago
Pointers are super hard if you've not dealt with indirection before. Especially in C/C++ when you can dereference pretty much anything and you get a runtime segfault with no other diagnostic. Do you not remember when that was mystifying? Given that a huge fraction of vulnerabilities are unsafe memory accesses, I think most people still make plenty of mistakes around pointers. The analogy I like is the address of IHOP (International House of Pancakes). If I know the address of IHOP is 4567 Portobello Rd., why don't I have pancakes?!? It's the same with a pointer. Similarly, if I have a pancake, and someone calls and asks me for the address of IHOP, it's also wrong to bring the pancake to them in lieu of the address.

spaetzleesser 6y ago

Same here. After I read K&R C's memory model seemed pretty simple and straightforward. Whenever I have trouble figuring out something I usually draw a little diagram with the memory space, where things are allocated and how handles and pointers relate to the memory space.

michaelbrave 6y ago

When I got started I found the syntax of it confusing, like why doesn't de-referencing look more distinct kind of thing. I got used to it eventually but it didn't feel very clear at first.

Corazoor 6y ago

I could read and write commodore 128 assembler before I started to learn C, so I knew about adresses, adressing modes and how to use them. Despite that, I still had trouble wrapping my head around the concept of pointers at first. There are multiple things that can make it confusing, and they kinda collude to make it harder to get. In order to understand them at all, you have to know - what a variable represents (a region of memory) - what an adress/reference is (the index of said region in memory) - how a value is stored in and read from said variable (by putting it into or reading from the memory beginnen at this adress) - that you actually can treat an adress as a value, i.e store it in another variable Thats already four deeply related, but still different things you have to wrap your head around. To make matters worse, the way pointers often are used (and most of the time introduced), is to point to another variable. Now you have two adresses, and two values, one of wich is one of the adresses. If that sentence confuses you, that is how beginners feel about it as well! Dereferencing is not straightforward either: It makes a pointer behave as if it were the pointed to variable, which in the usual introductory toy examples makes it look like a totally unnecessary and useless operation. Also the size of the pointed to variable is encoded via the pointers type, and does not have to match the size of the actually pointed to thing. Another mindblower that one. Lastly there is the linguistic problem that we tend to say a variable IS its value. Which is actually misleading in multiple ways if a variable contains the adress of another one. Ultimately I had to understand what pointers are NOT, in order to finally grasp what they are.

pjmlp 6y ago
Did the 128 Assembler not support declaring variables? I was already using variables, arrays and structs on MS-DOS/Amiga macro Assemblers.
- Corazoor 6y ago
  While there were macro assemblers, all I did use was the built-in machine monitor, which was basically a system provided debugger. But you could assemble single mnemonics into a memory location of your choosing, so I would put programs together directly in memory, one instruction at a time. That required counting their length as well, and doesn't support any constructs that span multiple instructions, like macros or variables... I knew variables already from commodore Basic, which i learned first. But there was no concept of pointers, direct interaction with memory happened via peek and poke, and the adress space was so small, you just chose an adress where to put your stuff and worked with offsets. It is worth remembering that on these old machines there was no OS managed memory allocation... So there was much less need to work with adresses unknown at "compile time".