Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointers in C (2010)

boredzo.org

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Pointers in C (2010)

#11

Post by aasasd »

Ah, boxes again.

For me, all confusion about C's pointer-happiness cleared up when I finally realized that C (and Asm, I guess) works with heap memory as a big blob of bytes, and it's programmer's job to keep the blob's contents from getting messed up―with some thinly-veiled help from the language and the compiler. Everything else, including variables, is just syntactic sugar when it points to the heap.

(With the clarification that afaik variables are different when they're on the stack or registers, becoming first-class 'indivisible' entities).

Re: Pointers in C (2010)

#12

Post by aasasd »

macintux wrote: post #5

I don’t have my copy at hand, but Expert C Programming: Deep C Secrets has the best coverage of pointers and arrays I’ve seen. In particular, it supplies a useful algorithm for decoding all pointer declarations such as functions that return function pointers. https://www.goodreads.com/book/show/198207

I'm guessing that the algorithm may be the spiral rule: http://c-faq.com/decl/spiral.anderson.html

Re: Pointers in C (2010)

#13

Post by macintux »

aasasd wrote: post #12
macintux wrote: post #5

I don’t have my copy at hand, but Expert C Programming: Deep C Secrets has the best coverage of pointers and arrays I’ve seen. In particular, it supplies a useful algorithm for decoding all pointer declarations such as functions that return function pointers. https://www.goodreads.com/book/show/198207

I'm guessing that the algorithm may be the spiral rule: http://c-faq.com/decl/spiral.anderson.html

From memory, I’d say it follows that basic strategy but is a bit more verbose and easier to follow.

Re: Pointers in C (2010)

#14

Post by roenxi »

maxxxxx wrote: post #2

I always wonder what makes pointers so difficult for some. So far I have always been able to explain it to people by drawing a linear memory space and then showing how different types are allocated. It seems to me that pointers are one the easier concepts in programming.

Pointers require a very clear mental separation between the thing and the location where the thing is stored. However, in C the thing is only really identifiable by the place it is stored.

If the learner's mental model of what is happening has any flaws whatsoever, it will break under that strain. There are a few complicated concepts that are very similar but not quite the same.

Re: Pointers in C (2010)

#16

Post by jandrese »

_kst_ wrote: post #4

I checked the section "Interlude: Arrays" because the relationship between pointers and arrays in C is a major sticking point. It claims that, given a declaration int array[] = { 45, 67, 89 }; the expressions "array", "&array", and "&array[0]" are all equivalent. They are not. "&array" and "&array[0]" both refer to the same memory location, but they're of different types. In the next section: "By the way, though size…

Is there a valid use case for doing pointer arithmetic on a void pointer? It just seems so disgusting on the surface. Did someone just really not want to bother casting to uint8_t*?

As for the array types, I think maybe the article is really trying to say that they'll all compile down to the same thing in the end (probably...compilers can be weird sometimes).

Re: Pointers in C (2010)

#17

Post by coliveira »

aasasd wrote: post #11

Ah, boxes again. For me, all confusion about C's pointer-happiness cleared up when I finally realized that C (and Asm, I guess) works with heap memory as a big blob of bytes, and it's programmer's job to keep the blob's contents from getting messed up―with some thinly-veiled help from the language and the compiler. Everything else, including variables, is just syntactic sugar when it points to the heap. (With the cla…

Pointers work just as well with heap allocated or stack allocated variables.

Re: Pointers in C (2010)

#19

Post by torstenvl »

jandrese wrote: post #16
_kst_ wrote: post #4

I checked the section "Interlude: Arrays" because the relationship between pointers and arrays in C is a major sticking point. It claims that, given a declaration int array[] = { 45, 67, 89 }; the expressions "array", "&array", and "&array[0]" are all equivalent. They are not. "&array" and "&array[0]" both refer to the same memory location, but they're of different types. In the next section: "By the way, though size…

Is there a valid use case for doing pointer arithmetic on a void pointer? It just seems so disgusting on the surface. Did someone just really not want to bother casting to uint8_t*? As for the array types, I think maybe the article is really trying to say that they'll all compile down to the same thing in the end (probably...compilers can be weird sometimes).

Casting to uint8_t* is not portable either, so it's not particularly better than using compiler extensions that let you increment void*.

Re: Pointers in C (2010)

#20

Post by rags2riches »

maxxxxx wrote: post #2

I always wonder what makes pointers so difficult for some. So far I have always been able to explain it to people by drawing a linear memory space and then showing how different types are allocated. It seems to me that pointers are one the easier concepts in programming.

I vaguely remember the first few times I wanted to do something more than paste magic snippets to my .emacs file. I knew nothing about Lisp and was not much of a programmer overall. The concepts of symbols and quoting were somehow really hard to grasp. It's strange now to imagine what was so hard then.

I have no memory of pointers being a hurdle like that. But I guess the concepts are somewhat similar so there probably was a time like that with pointers also.

Post reply on HN