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

The 5-minute Guide to C Pointers

denniskubes.com

Post reply on HN
Print view View original

31–40 of 75 posts

Re: The 5-minute Guide to C Pointers

#31

Post by sausagefeet »

When printfing pointers you need to cast them to (void\). %p only prints void\ and there is no guarantee two pointer types have the same size. And I can't figure out how to write an astrix.

I also think it is a mistake to bring up memory addresses so early. The first paragraph is incredibly confuses.

A pointer is simple. It's a variable that points at something. You can change where it points and you can change the value that it is pointing to. (&) is the pointer-to operator and gives you a pointer to something.

I think that is roughly all that needs to be said. The all of locations, memory, addresses is just confusion.

Re: The 5-minute Guide to C Pointers

#32

Post by RegEx »

eswangren wrote: post #28
ninetax wrote: post #22

Earlier quoted context omitted.

Well for a quick sum up: An array is like a constant pointer, it's always pointing at the first element of the the array. To try to point it at something else is an error. array[2] is short for *(array + 2*sizeof( )) which takes the address of the first element and adds the appropriate number of bytes to it in order to access the requested element, then it dereferences the "pointer" and you get the value of the eleme…

Just as with pointer arithmetic (because that's what this actually is) you don't multiply by the size of its elements. This: array[2] is the same as this: *(array + 2) The compiler knows what the type of data the pointer refers to and can produce the byte offset itself. Also: "...it's always pointing at the first element of the the array" Eh... an array can degrade into a pointer when needed, but what does the follow…

Additionally, (as you know, but merely pointing out for the curious), `sizeof arr` returns the size of arr in bytes, not the size of a pointer to the first element of arr.

Re: The 5-minute Guide to C Pointers

#33

Post by RegEx »

keporahg wrote: post #27
khakimov wrote: post #12

thanks, also recommend to read "What do people find difficult about C pointers?" http://stackoverflow.com/questions/4025768/what-do-people-fi...

I never really had much of a problem with the syntax, but the point at which the behavior of pointers really clicked for me (after a night of many segfaults of course) was when I realized that when you pass a pointer to a function, you're sending a copy of that pointer, just like with any other primitive type. E.g: void foo(int *p) { /* assignment won't be persistent after foo() returns; need to send **p */ p = (int…

I experienced the same frustration. The exercise that gave me the "ah-ha!" moment I needed was prepending to a linked list via the head instead of the tail: You need to pass the address of `head` into the function so that the new head is reflected in the calling environment when you say `head = np`.

Re: The 5-minute Guide to C Pointers

#34

Post by RegEx »

mauchter wrote: post #9
denniskubes wrote: post #4

Earlier quoted context omitted.

What is broken about it? I am happy to make corrections.

> On lines 15-16 we assign our void pointer back to our castptr int pointer. Notice the explicit cast needed. The explicit cast is not needed in C.

Correct. This is also why you do not need to cast the result of malloc(). An assignment of a pointer to void to another pointer initiates an implicit conversion.

Re: The 5-minute Guide to C Pointers

#35

Post by zaptheimpaler »

jakejake wrote: post #23
rosser wrote: post #10

Every time someone tries offering a simplified explanation of pointers, I've countered with the old Buddhist saying that, "The pointing finger is not the moon," followed by a brief foray into syntax and operators, e.g., moon* finger = &luna; As often as not, enlightenment occurs.

To me your line of code seems a bit too clever and complicates the concept of pointers. But we all learn differently so it's cool if it flips a switch for people who are, perhaps, more philosophical than I. I tend to use more boring examples like a card catalog vs a book when I'm explaining the idea of pointers.

Why do you say its clever/complicated? The example he mentioned seems like a fairly basic example of a pointer.

Re: The 5-minute Guide to C Pointers

#36

Post by zaptheimpaler »

pjmlp wrote: post #30

Nice tutorial! Maybe it shows my age, but I am yet to understand why so many developers nowadays have such a hard time grasping pointers, regardless of the language being used to teach them.

I had the same opinion at one point. Like you said, the concept of pointers is very simple, but it can get confusing in application, as you start dealing with more levels of indirection. Try coding something/understanding code that requires triple star pointers, then you'll see why they're confusing.

Re: The 5-minute Guide to C Pointers

#37

Post by wyclif »

phao wrote: post #20
wyclif wrote: post #19

Earlier quoted context omitted.

It would be super cool if you would just point to what you think is the better stuff with a link.

Sorry. I don't know why I didn't do it. http://www.iso-9899.info/ This is that wiki page I mentioned. It has links to all sorts of places. All articles I was talking about, I found in there. It has an articles page: http://www.iso-9899.info/wiki/C_gotchas And it has some recommendations on many things, including other artigles. http://www.iso-9899.info/wiki/Usenet Check out the "Additional materials part": http://www…

Thanks, I appreciate that.

Re: The 5-minute Guide to C Pointers

#38

Post by [deleted] »

_kst_ wrote: post #13

> Imagine an array variable like a pointer that cannot be changed that holds the memory address of the first element of the array it points to. Nope. Arrays are not pointers; pointers are not arrays. This is perhaps the most common misconception about C, and a "Guide to C Pointers" should not propagate it. For more information about why this is wrong, read section 6 of the [comp.lang.c FAQ]( http://www.c-faq.com ).

[deleted]

Re: The 5-minute Guide to C Pointers

#39

Post by sown »

Pointers are sometimes not arrays. :)

    extern int *x;
    extern int y[]
x is a pointer to an int and y is a pointer to an array of ints of unspecified size. It's equivalent to saying float x and then extern int x somewhere else. They're type mismatched.

If you said 'x is a char pointer', you mean lookup symbol table for address of x, then do a memory address dereference and then get the contents of the memory at dereferenced address.

If you said 'x is a char array', you mean use the symbol table to get the address, then calculate offset and get contents from that address.

When you define it one way and then do it another, you end up doing both of those above. get contents of x, then get value of offset, add it to the contents of x, then get contents of the resulting address+offset.

The issue is the declaration which can happen many times and the definition which occurs just once.

Now, you can have an array and a pointer be equivalent if it is used in an expression because the compiler converts array references to pointers.

Re: The 5-minute Guide to C Pointers

#40

Post by acqq »

greenyoda wrote: post #25
denniskubes wrote: post #16

Earlier quoted context omitted.

Thanks to everybody for the suggestions. I made some changes to denote addressof and better explain arrays. Also stated that the explicit cast wasn't needed.

A couple more things: - There's nothing special about uninitialized pointers in C. Any uninitialized variable, whether it's a pointer, int, double, etc., contains unpredictable bytes left over from whatever was previously in that memory location, and should not be referenced. Not sure why this belongs in an article that's specifically about pointers. - You should proofread the whole thing and fix the typos that a spe…

Exactly, as soon as I saw "pointers can be null or uninitialized" my thought was "this is a really confused soul who wants to teach others."

I made my own compilers for living but I find the text very confusing. I'm glad I didn't have to learn anything from this text. I still believe people should learn C from this book:

http://en.wikipedia.org/wiki/The_C_Programming_Language

It's not so big and it's really good written.

Post reply on HN