The 5-minute Guide to C Pointers • Hacker News Board

Re: The 5-minute Guide to C Pointers

#21

Post by phao » Thu, Aug 16, 2012, 5:36 AM UTC

wyclif wrote: post #19

phao wrote: post #15

Earlier quoted context omitted.

Honestly, why don't you re-iterate the known tutorials about these things? Make a blog post saying "here are these old C tutorials, which are amazing; and some people seem to have forgotten these things" and post them. Lots of comp.lang.c posts are interest Chris Torek's stuff are interesting. If you go to the ##c channel, at irc.freenode.com, they have a wiki link on the topic. That wiki has links to many tutorials.…

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

This Chris Torek guy has a bunch of articles. Series called "C for smarties". It's __very__ good.

http://web.torek.net/torek/c/

The link is in there in the wiki somewhere, but I think it's worth placing it separately.

The wiki mentions some names in the Usenet page. Google these names.

Re: The 5-minute Guide to C Pointers

#22

Post by ninetax » Thu, Aug 16, 2012, 5:45 AM UTC

_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 ).

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 element.

If this isn't 100% correct, please let me know.

Re: The 5-minute Guide to C Pointers

#23

Post by jakejake » Thu, Aug 16, 2012, 5:58 AM UTC

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.

Re: The 5-minute Guide to C Pointers

#24

Post by RegEx » Thu, Aug 16, 2012, 5:59 AM UTC

ninetax wrote: post #22

_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 ).

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…

From the C standard:

> The definition of the subscript operator [] is that E1[E2] is identical to (((E1)+(E2))).

So array[2] == (array + 2)

Re: The 5-minute Guide to C Pointers

#25

Post by greenyoda » Thu, Aug 16, 2012, 6:02 AM UTC

denniskubes wrote: post #16

denniskubes wrote: post #4

Earlier quoted context omitted.

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

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 spelling checker won't pick up, e.g., "garage" should be "garbage".

Re: The 5-minute Guide to C Pointers

#26

Post by dbaupp » Thu, Aug 16, 2012, 6:06 AM UTC

ninetax wrote: post #22

_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 ).

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…

As RegEx implies, pointer arithmetic implicitly includes the sizeof() term, i.e. given

  int* array;

then

  array + 1

points to the next int, not the next byte. And so array[2] == *(array + 2). (The fact that addition commutes means that using 2[array] instead is valid and works in C.)

Re: The 5-minute Guide to C Pointers

#27

Post by keporahg » Thu, Aug 16, 2012, 6:07 AM UTC

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 *)malloc(1024 * sizeof(int));
    }

Not sure why my brain had decided to make an exception for pointers for the rule that all variables are passed as copies when I first learned C, but after that I never had any problems.

Re: The 5-minute Guide to C Pointers

#28

Post by eswangren » Thu, Aug 16, 2012, 6:07 AM UTC

ninetax wrote: post #22

_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 ).

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 following produce?

  char arr[10];
  ??? x = &arr;

Is "x" a pointer to pointer to char? From your assessment it would seem so, but in reality the type of "x" is

  char (*)[10]

i.e., pointer to array of char 10. An array is an array, and arrays can degrade into pointer types.

Re: The 5-minute Guide to C Pointers

#29

Post by RegEx » Thu, Aug 16, 2012, 6:08 AM UTC

phao wrote: post #18

denniskubes wrote: post #17

Earlier quoted context omitted.

You have some valid points. I clarified the arrays section. I am just attempting to show some simple examples. Wasn't trying to do anything in depth. Not the easiest things with pointers of course.

Very few people have reasons to use C. As far as I know, must people do not want to use C. Those who want or have reason to, should go in depth. If you're trying to avoid going deep on the subject, then, forgive my intrusion, maybe you should be focusing on something else. Some languages you can use by just learning a little bit here and there, supperficially. C is not one of these.

I'd wager a good number of people don't want to use C because many intro tutorials are too pedantic, too clever, and/or too intimidating. C doesn't have to be hard. I agree that the OP should work to retain 100% accuracy in his article, but I disagree that he should fledge out "the truth" to its fullest extent for a beginner. There's always a level deeper you can go in learning how pointers/memory/hardware/transistors work. Deciding the extent of information you wish to impart before letting the beginner do some programming is a very delicate decision.

Re: The 5-minute Guide to C Pointers

#30

Post by pjmlp » Thu, Aug 16, 2012, 6:20 AM UTC

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.