4 ms·

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter i

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter is what makes C-style pointer arithmetic possible, because if you know the type, you know its size too.

deleted 8y ago
[deleted]
- kazinator 8y ago
  C pointers being typed is absolutely central. Firstly, because a pointer is typed, when we dereference it, the memory location is accessed properly as the type. We don't have to put anything in the expression to say "please access the memory as 'struct foo', or a 'double'". Secondly, arithmetic on pointers for array-like manipulation uses correct displacements for the size of the type. Thirdly, we get error checking: there is a good amount of resistance in the language against mixing up types. If we convert one type of pointer to another without a cast, we get a diagnostic. All these aspects are a key aspect of what separates C from assembly language.
  - deleted 8y ago
    [deleted]
  - torstenvl 8y ago
    > C pointers being typed is absolutely central. No it isn't. The rest of your post shows why. > Firstly, because a pointer is typed, when we dereference it Nonsensical and circular. > Secondly, arithmetic on pointers... Nonsensical and circular. > Thirdly, we get error checking: there is a good amount of resistance in the language against mixing up types. If we convert one type of pointer... Circular. Every single one of your points about why this is an important property of pointers presupposes that the reader knows what a pointer is and how it works. It's a fundamental truism that you can't introduce, explain, and define a term using the term itself. The OP's introduction does not suffer from this problem, which is why it is superior to your proposal. (Edit: You all can downvote me all you want, but you're still objectively wrong.)
    - kazinator 8y ago
      > Every single one of your points ... presupposes that the reader knows what a pointer is and how it works. Pardon my mistake; I made these points under the belief that I'm in a debate about how to teach pointers to a beginner audience, not that I'm addressing that audience itself.
      - torstenvl 8y ago
        Distinction without a difference. If you can't explain to your students why the words out of your mouth are useful, you've already lost them. The fact of the matter is that you're getting hung up on implementation details that do nothing to explain the concept. Pointer arithmetic, how pointers interact with the type system... those are important, but they're completely incidental. There's no fundamental reason C had to implement pointers that way. They're factoids about how pointers work in C, practical mechanics. They tell you nothing about what pointers are in essence: a memory address. And I don't know if you've worked with novice programmers lately, but it seems pretty obvious to me - based on how so many people get their heads discombobulated about pointers - that that conceptual clarity is needed. The details you're listing don't need to be in the first sentence.
        kazinator 8y ago
        That C pointers have a type which is used for checking, semantics of memory access and arithmetic falls into a category that I like to call requirements, whereas I use the word implementation detail for something like how many bits are in a pointer, and do pointers to bytes have the same representation as pointers to wider types. (These are also requirements, but ones an implementation can vary.) I accept your terminology, though. Let the key features of C be called "implementation details". Then, if the goal is to teach C, it is "implementation details" we must teach. (In any case, the students are probably eager to learn implementation details in the regular sense also, otherwise they would have been satisfied with their Python or Javascript class.) If what you really mean is that we should teach C by instead teaching the architecture of a machine, whereby C is treated as just a notation for manipulating that machine, and concepts like the type system are considered annoying/distracting details in that notation, then I strongly disagree. Even if it is easier to teach that way, and the students eagerly absorb and regurgitate the simplified misconceptions, they are ill served.
deleted 8y ago
[deleted]
vram22 8y ago
Right. That's why, when you have an array of structs, say each 8 bytes in size, and a pointer ptr to the start of it, each time you do: ptr++; it increments the address stored in ptr, not by 1, but by 8 (bytes) - so as to now point to the next struct in the array. Same if you do: ptr--; except in that case it decrements the address by 8. And if you did: ptr += 2; it would increment the address in ptr to point to 16 bytes further ahead in memory than it was earlier, for the same reason. ptr will now point to the struct which is two items further ahead in the array. So you can access that struct with the expression: *ptr

deleted 8y ago

[deleted]

kazinator 8y ago
C pointers being typed is absolutely central. Firstly, because a pointer is typed, when we dereference it, the memory location is accessed properly as the type. We don't have to put anything in the expression to say "please access the memory as 'struct foo', or a 'double'". Secondly, arithmetic on pointers for array-like manipulation uses correct displacements for the size of the type. Thirdly, we get error checking: there is a good amount of resistance in the language against mixing up types. If we convert one type of pointer to another without a cast, we get a diagnostic. All these aspects are a key aspect of what separates C from assembly language.
- deleted 8y ago
  [deleted]
- torstenvl 8y ago
  > C pointers being typed is absolutely central. No it isn't. The rest of your post shows why. > Firstly, because a pointer is typed, when we dereference it Nonsensical and circular. > Secondly, arithmetic on pointers... Nonsensical and circular. > Thirdly, we get error checking: there is a good amount of resistance in the language against mixing up types. If we convert one type of pointer... Circular. Every single one of your points about why this is an important property of pointers presupposes that the reader knows what a pointer is and how it works. It's a fundamental truism that you can't introduce, explain, and define a term using the term itself. The OP's introduction does not suffer from this problem, which is why it is superior to your proposal. (Edit: You all can downvote me all you want, but you're still objectively wrong.)
  - kazinator 8y ago
    > Every single one of your points ... presupposes that the reader knows what a pointer is and how it works. Pardon my mistake; I made these points under the belief that I'm in a debate about how to teach pointers to a beginner audience, not that I'm addressing that audience itself.
    - torstenvl 8y ago
      Distinction without a difference. If you can't explain to your students why the words out of your mouth are useful, you've already lost them. The fact of the matter is that you're getting hung up on implementation details that do nothing to explain the concept. Pointer arithmetic, how pointers interact with the type system... those are important, but they're completely incidental. There's no fundamental reason C had to implement pointers that way. They're factoids about how pointers work in C, practical mechanics. They tell you nothing about what pointers are in essence: a memory address. And I don't know if you've worked with novice programmers lately, but it seems pretty obvious to me - based on how so many people get their heads discombobulated about pointers - that that conceptual clarity is needed. The details you're listing don't need to be in the first sentence.
      - kazinator 8y ago
        That C pointers have a type which is used for checking, semantics of memory access and arithmetic falls into a category that I like to call requirements, whereas I use the word implementation detail for something like how many bits are in a pointer, and do pointers to bytes have the same representation as pointers to wider types. (These are also requirements, but ones an implementation can vary.) I accept your terminology, though. Let the key features of C be called "implementation details". Then, if the goal is to teach C, it is "implementation details" we must teach. (In any case, the students are probably eager to learn implementation details in the regular sense also, otherwise they would have been satisfied with their Python or Javascript class.) If what you really mean is that we should teach C by instead teaching the architecture of a machine, whereby C is treated as just a notation for manipulating that machine, and concepts like the type system are considered annoying/distracting details in that notation, then I strongly disagree. Even if it is easier to teach that way, and the students eagerly absorb and regurgitate the simplified misconceptions, they are ill served.

deleted 8y ago

[deleted]

vram22 8y ago

Right. That's why, when you have an array of structs, say each 8 bytes in size, and a pointer ptr to the start of it, each time you do: ptr++; it increments the address stored in ptr, not by 1, but by 8 (bytes) - so as to now point to the next struct in the array. Same if you do: ptr--; except in that case it decrements the address by 8. And if you did: ptr += 2; it would increment the address in ptr to point to 16 bytes further ahead in memory than it was earlier, for the same reason. ptr will now point to the struct which is two items further ahead in the array. So you can access that struct with the expression: *ptr