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

61–70 of 113 posts

Re: Pointers in C (2010)

#61

Post by plasticchris »

monk_e_boy wrote: post #59
_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…

Dude, I've just been asked to teach c pointers and this was super helpful. Got a good c++ FAQ? :)

Marshall Cline made a good one, here's a mirror, the original seems down: http://www.dietmar-kuehl.de/mirror/c++-faq/references.html

Re: Pointers in C (2010)

#62

Post by romeisendcoming »

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…

Yes, this. The more you use a debugger the more it becomes apparent that C accesses OS protected domain and the best the OS can do is complain and stop you if you aren't smart enough to continue.

Re: Pointers in C (2010)

#63

Post by [deleted] »

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?

[deleted]

Re: Pointers in C (2010)

#64

Post by [deleted] »

Stratoscope wrote: post #37
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.

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter is what makes C-style pointer arithmetic possible, because if you know the type, you know its size too.

[deleted]

Re: Pointers in C (2010)

#65

Post by p1esk »

DonHopkins wrote: post #29
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…

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"];

???

Re: Pointers in C (2010)

#66

Post by Merad »

Traubenfuchs wrote: post #46
n4r9 wrote: post #26

Earlier quoted context omitted.

C# and Java 8 (I believe) provide functional patterns. e.g. in C# the ToLower function which takes a string and returns a string can be used like: var lowercaseIds = ids.Select(ToLower)

You believe correctly, but naturally, it's a lot more verbose: var lowercaseIds = ids.stream().map(String::toLowerCase); and an additional .collect(Collectors.toList()) if you don't want a Stream instance. (var is Java 10, though I believe it should not be used in production code, ever)

> var is Java 10, though I believe it should not be used in production code, ever

Is that your opinion of var in general, or something about Java's implementation of it? If the former, I'm really curious why, as a C# dev who's used it for many years.

Re: Pointers in C (2010)

#67

Post by kazinator »

DonHopkins wrote: post #30
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.

Do you use "vi" or "emacs"? It's my opinion that "vi" warps your mind about how pointers work, with its cursor that can't decide whether it's BETWEEN characters and OVER characters. https://unix.stackexchange.com/questions/11402/why-does-esc-... >Why does `ESC` move the cursor back in vim? >In insert mode, the cursor is between characters, or before the first or after the last character. In normal mode, the cursor is…

I tried to investigate what it would take for Vim to have a mode where the cursor is between characters (so that the I-beam shape can be used for the cursor).

That is, this would be for the purposes of visual selection with 'v'. It now includes the character under the cursor, which makes no sense when the cursor is a vertical bar that is to the left of the character.

The code is so contorted and poorly modularized, it would have to change in numerous places; I estimated it at a minimum of two weeks of full time work to ramp up on the internals sufficiently to be able to add the feature with reasonable confidence.

Re: Pointers in C (2010)

#68

Post by kazinator »

emmelaich wrote: post #32
_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…

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.

Re: Pointers in C (2010)

#69

Post by kazinator »

[deleted] wrote: post #64
Stratoscope wrote: post #37

Earlier quoted context omitted.

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter is what makes C-style pointer arithmetic possible, because if you know the type, you know its size too.

[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: there is a good amount of resistance in the language against mixing up types. If we convert one type of pointer to another without a cast, we get a diagnostic.

All these aspects are a key aspect of what separates C from assembly language.

Re: Pointers in C (2010)

#70

Post by [deleted] »

Stratoscope wrote: post #37
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.

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter is what makes C-style pointer arithmetic possible, because if you know the type, you know its size too.

[deleted]
Post reply on HN