4 ms·

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

by aasasd 8y ago

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 clarification that afaik variables are different when they're on the stack or registers, becoming first-class 'indivisible' entities).

coliveira 8y ago
Pointers work just as well with heap allocated or stack allocated variables.
deleted 8y ago
[deleted]
DonHopkins 8y ago
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
- huhtenberg 8y ago
  > Peek and Poke Now that's the words I haven't heard in a long time.
- danlugo92 8y ago
  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 8y ago
    [deleted]
  - aasasd 8y ago
    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.
- p1esk 8y ago
  char theLetterC = 2["ABC"]; ???
  - DonHopkins 8y ago
    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.
- vram22 8y ago
  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 years ago, at first didn't believe it, and remember trying it out on at least a Windows C compiler (MS C, likely) and maybe GCC on Linux as well. Worked on both, no compiler error. This works because the expression arr, while we think of it as the name of the declared array, is also a synonym for the address of the first memory location of the array. Note: all that I wrote above is what I rememeber from using ANSI C (a lot, but some years earlier). Things may have changed some with C99, etc.
  - vram22 8y ago
    >rememeber remember
romeisendcoming 8y ago
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.
porpoisely 8y ago
Pointers aren't just heap specific. Pointers are a language type that can reference memory address ( stack, heap, null or anywhere really ). It's why you can have stack overflow, heap overflow, etc via pointer bugs. Also, C/C++/etc runtimes don't have garbage collection but that's a runtime issue not a language specific issue/type system issue. I think you have a good understanding of pointers, but you are mistakenly confining it to the heap or the runtime. Pointers part of the language and the type system.

by aasasd 8y ago

coliveira 8y ago

Pointers work just as well with heap allocated or stack allocated variables.

deleted 8y ago

[deleted]

DonHopkins 8y ago

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

huhtenberg 8y ago
> Peek and Poke Now that's the words I haven't heard in a long time.
danlugo92 8y ago
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 8y ago
  [deleted]
- aasasd 8y ago
  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.
p1esk 8y ago
char theLetterC = 2["ABC"]; ???
- DonHopkins 8y ago
  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.
vram22 8y ago
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 years ago, at first didn't believe it, and remember trying it out on at least a Windows C compiler (MS C, likely) and maybe GCC on Linux as well. Worked on both, no compiler error. This works because the expression arr, while we think of it as the name of the declared array, is also a synonym for the address of the first memory location of the array. Note: all that I wrote above is what I rememeber from using ANSI C (a lot, but some years earlier). Things may have changed some with C99, etc.
- vram22 8y ago
  >rememeber remember

romeisendcoming 8y ago

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.

porpoisely 8y ago

Pointers aren't just heap specific. Pointers are a language type that can reference memory address ( stack, heap, null or anywhere really ). It's why you can have stack overflow, heap overflow, etc via pointer bugs. Also, C/C++/etc runtimes don't have garbage collection but that's a runtime issue not a language specific issue/type system issue. I think you have a good understanding of pointers, but you are mistakenly confining it to the heap or the runtime. Pointers part of the language and the type system.