Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything you need to know about pointers in C (2010)

boredzo.org

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Everything you need to know about pointers in C (2010)

#11

Post by flohofwoe »

jasode wrote: post #3
ChrisSD wrote: post #2

> A pointer is a memory address. This is an amazingly wrong statement. In assembly you deal with memory addresses. Pointers in C are a much higher level abstraction. > On current mainstream Intel processors, it occupies four bytes of memory (because an int is four bytes wide). This depends on the compiler as well as the processor.

>This depends on the compiler as well as the processor. Yes. On x64 compilers targeting 64bit cpus, the following prints 8 instead of 4: #include int main () { std::cout

The article talks about the size of the pointee in memory though, not the size of the pointer.

An 'int' is usually 4 bytes wide when compiling for 64-bit ISAs (at least I haven't seen situations yet where this isn't the case, my experience is limited to x86 and ARM though). Modern C fixes this ambiguity with sized integer types (e.g. int32_t vs int64_t).

Re: Everything you need to know about pointers in C (2010)

#12

Post by weltensturm »

By C half-assedly trying to make "* " part of the name, just so you can use "* ptr" everywhere like it is an actual variable name, you get confusions such as this.

First "foo_ptr's type is int * ", but then "The pointer has a type, too, by the way. Its type is int.".

I also refuse to agree with "An int * * 's type is int * ". :)

But I guess "the type of `* ptr` is int, the type of `ptr` is int * " would be even more confusing.

Re: Everything you need to know about pointers in C (2010)

#13

Post by pjc50 »

ChrisSD wrote: post #2

> A pointer is a memory address. This is an amazingly wrong statement. In assembly you deal with memory addresses. Pointers in C are a much higher level abstraction. > On current mainstream Intel processors, it occupies four bytes of memory (because an int is four bytes wide). This depends on the compiler as well as the processor.

> Pointers in C are a much higher level abstraction.

Not really; almost all programmers treat them as addresses and almost all compilers represent them that way. Regardless of what the standard actually says. Leading to surprises when this doesn't hold true, and awkwardnesses of the 16-bit x86 "near/far" pointers.

I mean, that's the only reason that "array[index]" and "index[array]" are interchangeable; you don't see that in other languages.

Re: Everything you need to know about pointers in C (2010)

#14

Post by MaxBarraclough »

weltensturm wrote: post #12

By C half-assedly trying to make "* " part of the name, just so you can use "* ptr" everywhere like it is an actual variable name, you get confusions such as this. First "foo_ptr's type is int * ", but then "The pointer has a type, too, by the way. Its type is int.". I also refuse to agree with "An int * * 's type is int * ". :) But I guess "the type of `* ptr` is int, the type of `ptr` is int * " would be even more…

It's a pretty bad syntax.

A demonstration of a declaration statement where the asterisk operator binds to an identifier rather than to a type:

    int my_int, *my_ptr, my_other_int;
A demonstration of a different declaration where the asterisk operator does not bind to an identifier, as an identifier isn't even needed:

    extern void my_function(int*, char*);
So the real answer is that it depends on what you're doing. Terribly clunky.

Interestingly the D programming language mostly keeps C's syntax, but handles multiple declarations differently. https://dlang.org/spec/declaration.html#declaration_syntax

Re: Everything you need to know about pointers in C (2010)

#15

Post by slmjkdbtl »

The time [0] I found out about ptr_b in

  int* ptr_a, ptr_b;
isn't actually initialized as a pointer I changed all my C code to marking * before the variable name, fun times. It's helpful to think int as the base type and * the indicator of functionality like [] and ().

Also just found out the author was the developer of Adium [1], which is one of my favorite softwares (best logo) on macOS.

[0] http://c-faq.com/decl/charstarws.html

[1] https://adium.im/

Re: Everything you need to know about pointers in C (2010)

#16

Post by amelius »

ChrisSD wrote: post #2

> A pointer is a memory address. This is an amazingly wrong statement. In assembly you deal with memory addresses. Pointers in C are a much higher level abstraction. > On current mainstream Intel processors, it occupies four bytes of memory (because an int is four bytes wide). This depends on the compiler as well as the processor.

What higher level abstraction do pointers bring to the table over plain memory addresses other than pointer-arithmetic?

Re: Everything you need to know about pointers in C (2010)

#17

Post by sai_c »

slmjkdbtl wrote: post #15

The time [0] I found out about ptr_b in int* ptr_a, ptr_b; isn't actually initialized as a pointer I changed all my C code to marking * before the variable name, fun times. It's helpful to think int as the base type and * the indicator of functionality like [] and (). Also just found out the author was the developer of Adium [1], which is one of my favorite softwares (best logo) on macOS. [0] http://c-faq.com/decl/ch…

Besides writing

  "int *p"
instead of

  "int* p"
I also always use one line per variable declaration, which should avoid confusion when the first style is used. But that's my personal preference.

Edit: corrected code quotation.

Re: Everything you need to know about pointers in C (2010)

#18

Post by ogogmad »

sai_c wrote: post #17
slmjkdbtl wrote: post #15

The time [0] I found out about ptr_b in int* ptr_a, ptr_b; isn't actually initialized as a pointer I changed all my C code to marking * before the variable name, fun times. It's helpful to think int as the base type and * the indicator of functionality like [] and (). Also just found out the author was the developer of Adium [1], which is one of my favorite softwares (best logo) on macOS. [0] http://c-faq.com/decl/ch…

Besides writing "int *p" instead of "int* p" I also always use one line per variable declaration, which should avoid confusion when the first style is used. But that's my personal preference. Edit: corrected code quotation.

When quoting code, leave a line and indent by two spaces.

Re: Everything you need to know about pointers in C (2010)

#19

Post by jasode »

flohofwoe wrote: post #11
jasode wrote: post #3

Earlier quoted context omitted.

>This depends on the compiler as well as the processor. Yes. On x64 compilers targeting 64bit cpus, the following prints 8 instead of 4: #include int main () { std::cout

The article talks about the size of the pointee in memory though, not the size of the pointer. An 'int' is usually 4 bytes wide when compiling for 64-bit ISAs (at least I haven't seen situations yet where this isn't the case, my experience is limited to x86 and ARM though). Modern C fixes this ambiguity with sized integer types (e.g. int32_t vs int64_t).

>The article talks about the size of the pointee in memory though, not the size of the pointer.

Yes, you're right about the article's text. When I read gp ChrisSD's comment in isolation where he quotes ">A pointer is a memory address" -- followed immediately by him quoting ">On current mainstream Intel processors, _it_ occupies four bytes of memory"

... I thought the "_it_" was referring to a "pointer" instead of plain "int". It didn't occur to me to that the actual article has extra text in between those 2 extracted quotes which drastically changes the assumption of what the pronoun "it" means. My mistake.

Post reply on HN