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

81–90 of 113 posts

Re: Pointers in C (2010)

#81

Post by simias »

saagarjha wrote: post #43
simias wrote: post #39

Earlier quoted context omitted.

"char" is portable and by definition sizeof(char) == 1 and on top of that char pointers can alias other types. If I could time travel and influence the design of C the first things I'd do is change switch to break by default. The 2nd thing I'd do is rename "char" into "byte" since that's effectively what it is (and it's seldom a character these days since we often use UTF-8 or other multi-byte encodings).

> The 2nd thing I'd do is rename "char" into "byte" since that's effectively what it is This isn't always true. See machines where CHAR_BIT > 8.

A byte is the smallest addressable memory unit, nothing more, nothing less. It's true that on most modern machines it's always equal to 8 bits (and it's mandated by POSIX AFAIK) but that's orthogonal.

In French when talking about storage capacity we use "octet" instead of "byte", I always thought that made more literal sense (if you have a 1megabyte memory on a system where CHAR_BITS is 16, do you have 8 or 16 megabits?).

Re: Pointers in C (2010)

#82

Post by maxxxxx »

aasasd wrote: post #22
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.

My guess is, people are trying to keep variables the primary concept, and explain pointers on top of that. Hence, ‘boxes’ again crop up in an explanation of pointers. For me, everything became much more clear when I realized that the heap memory stands on its own as a concept, being a big pile of bytes instead of ‘boxes’—and implicit allocation/deallocation of variables is just a thin veil on top (muddying the matter…

I visualize memory as a big range and variables occupy space on them. The pointer is just the first byte of that space. Once you realize that C is basically placing stuff on memory things become pretty clear I think.

Re: Pointers in C (2010)

#83

Post by ape4 »

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.

That's a start but lots of beginners don't know when to use *ptr vs &thing vs ptr->member

Re: Pointers in C (2010)

#84

Post by maxxxxx »

ape4 wrote: post #83
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.

That's a start but lots of beginners don't know when to use *ptr vs &thing vs ptr->member

The syntax definitely could be improved. The equivalence of arrays and pointers is also confusing.

Re: Pointers in C (2010)

#85

Post by deogeo »

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

Re: Pointers in C (2010)

#86

Post by vram22 »

vram22 wrote: post #77
DonHopkins wrote: post #29

Earlier quoted context omitted.

My favorite proof that C arrays and strings are actually just syntactic sugar for pointer arithmetic is that the following are all valid and equivalent: char theLetterC = "ABC"[2]; char theLetterC = *("ABC" + 2); char theLetterC = *(2 + "ABC"); char theLetterC = 2["ABC"]; "You can't prove anything about a program written in C or FORTRAN. It's really just Peek and Poke with some syntactic sugar." -Bill Joy

Yes, that works because for an array arr and an int i, arr[i] (i'th element of array arr) is the same as *(arr + i) (the value at the memory address arr + i) which is the same (by commutativity) as *(i + arr) (the value at the memory address i + arr) which in turn is the same as i[arr] That last bit is what seems non-intuitive, but it is true. I first read about this, maybe in the K&R book or some other C book, many…

>rememeber

remember

Re: Pointers in C (2010)

#87

Post by aasasd »

danlugo92 wrote: post #60
DonHopkins wrote: post #29

Earlier quoted context omitted.

My favorite proof that C arrays and strings are actually just syntactic sugar for pointer arithmetic is that the following are all valid and equivalent: char theLetterC = "ABC"[2]; char theLetterC = *("ABC" + 2); char theLetterC = *(2 + "ABC"); char theLetterC = 2["ABC"]; "You can't prove anything about a program written in C or FORTRAN. It's really just Peek and Poke with some syntactic sugar." -Bill Joy

char theLetterC = 2["ABC"]; Wait, what? And I thought I was good with pointers... Edit: I think I got it, is it this?: "ABC" + 2 == 2["ABC"] == *(2 + "ABC") Right?

I'm not a C man, but afaiu, "ABC" is syntactic sugar for a char pointer to that string. So it works like any pointer with regard to index access.

Re: Pointers in C (2010)

#88

Post by torstenvl »

kazinator wrote: post #69
[deleted] wrote: post #64

Earlier quoted context omitted.

[deleted]

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

Re: Pointers in C (2010)

#89

Post by vardump »

simias wrote: post #81
saagarjha wrote: post #43

Earlier quoted context omitted.

> The 2nd thing I'd do is rename "char" into "byte" since that's effectively what it is This isn't always true. See machines where CHAR_BIT > 8.

A byte is the smallest addressable memory unit, nothing more, nothing less. It's true that on most modern machines it's always equal to 8 bits (and it's mandated by POSIX AFAIK) but that's orthogonal. In French when talking about storage capacity we use "octet" instead of "byte", I always thought that made more literal sense (if you have a 1megabyte memory on a system where CHAR_BITS is 16, do you have 8 or 16 megabi…

There are bit-addressable CPUs and DSPs. Examples are many microcontrollers (part of the memory accessible in bit-addressable windows), and famous TMS34010 (https://en.wikipedia.org/wiki/TMS34010).

4-bit CPUs (like the one in your toothbrush or thermometer) can also of course address 4-bit "words", "bytes" or nibbles.

So 8 bits might not be the smallest addressable memory unit.

Re: Pointers in C (2010)

#90

Post by DonHopkins »

p1esk wrote: post #65
DonHopkins wrote: post #29

Earlier quoted context omitted.

My favorite proof that C arrays and strings are actually just syntactic sugar for pointer arithmetic is that the following are all valid and equivalent: char theLetterC = "ABC"[2]; char theLetterC = *("ABC" + 2); char theLetterC = *(2 + "ABC"); char theLetterC = 2["ABC"]; "You can't prove anything about a program written in C or FORTRAN. It's really just Peek and Poke with some syntactic sugar." -Bill Joy

char theLetterC = 2["ABC"]; ???

In object oriented terms, the number two is an infinite map from all possible strings, to the third character of each string (or undefined behavior if the string length is too short). That just happens to be highly optimized in C. ;)

In Objective C, that would be [2 getNthCharacterOfCString: "ABC"];

Just joking! If you try to think about C in object oriented terms, you're misunderstanding what's really going on. It doesn't actually have arrays or strings as objects, they're just syntactic sugar (more like syntactic syrup of ipecac), and [] doesn't send a message. It's all just pointer arithmetic.

Post reply on HN