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

91–100 of 113 posts

Re: Pointers in C (2010)

#91

Post by emmelaich »

kazinator wrote: post #68
emmelaich wrote: post #32

Earlier quoted context omitted.

The C faq presents as supposedly common questions and answers without saying what a pointer is. In contrast I really like the posts definition. > A pointer is a memory address. Not perfect but for concision and accuracy it cannot be beat.

Problem is, the author isn't using that definition as a rung on Witgennstein's ladder. He believes it himself. That's why he's oblivious to the differences between array, &array and &array[0]. The expressions produce the same memory address and since that is what a pointer is by definition, they are equivalent.

> He believes it himself

Not necessarily a strong belief, just an amount of ignorance perhaps.

Re: Pointers in C (2010)

#92

Post by kazinator »

torstenvl wrote: post #88
kazinator wrote: post #69

Earlier quoted context omitted.

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:…

> 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 on…

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

Re: Pointers in C (2010)

#93

Post by DerekL »

deogeo wrote: post #85
_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…

> "&array" and "&array[0]" both refer to the same memory location, but they're of different types. "&array[0]" also does a dereference, which may cause undefined behaviour if array is null or invalid. You can get fun stuff like the optimizer omitting null checks later on.

Interesting. In C, “&array[0]“ is the same thing as “(array + 0)”, but in my copy of the C11 draft standard, I can't find anything about adding zero to a null pointer.

Re: Pointers in C (2010)

#94

Post by deogeo »

DerekL wrote: post #93
deogeo wrote: post #85

Earlier quoted context omitted.

> "&array" and "&array[0]" both refer to the same memory location, but they're of different types. "&array[0]" also does a dereference, which may cause undefined behaviour if array is null or invalid. You can get fun stuff like the optimizer omitting null checks later on.

Interesting. In C, “&array[0]“ is the same thing as “(array + 0)”, but in my copy of the C11 draft standard, I can't find anything about adding zero to a null pointer.

"&array[0]" is equivalent to "&(array[0])" - [] has greater precedence than &. Desugared, this is "&(*(array + 0))" - add 0, dereference, then take the address.

Re: Pointers in C (2010)

#95

Post by torstenvl »

kazinator wrote: post #92
torstenvl wrote: post #88

Earlier quoted context omitted.

> 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 on…

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

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.

Re: Pointers in C (2010)

#96

Post by kazinator »

torstenvl wrote: post #95
kazinator wrote: post #92

Earlier quoted context omitted.

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

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…

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.

Re: Pointers in C (2010)

#97

Post by [deleted] »

kazinator wrote: post #96
torstenvl wrote: post #95

Earlier quoted context omitted.

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…

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 termi…

[deleted]

Re: Pointers in C (2010)

#98

Post by dang »

kazinator wrote: post #92
torstenvl wrote: post #88

Earlier quoted context omitted.

> 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 on…

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

Come on, please don't be a jerk on HN.

Re: Pointers in C (2010)

#99

Post by dang »

torstenvl wrote: post #88
kazinator wrote: post #69

Earlier quoted context omitted.

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:…

> 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 on…

Please don't post in the flamewar style to HN. It leads to increasing nastiness, as happened below, and you did quite a bit to fuel that.

If you'd please review https://news.ycombinator.com/newsguidelines.html and take the spirit of this site to heart, we'd be grateful. We don't want threads to go up in flames.

Re: Pointers in C (2010)

#100

Post by dang »

[deleted] wrote: post #97
kazinator wrote: post #96

Earlier quoted context omitted.

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 termi…

[deleted]

Please stop now.
Post reply on HN