Thread: Using pointers to pointers

Originally Posted by jason_m

Something I read that helped me understand pointers goes something like this:

When you declare say an int, you say:

Code:

int var_name1;

When you declare a pointer to an int, you say:

Code:

int *var_name2;

The two look almost the same. If you ignore the "*" and think of it as part of the name of the variable, then you can use them the same way. So, where ever you may use "var_name1" in an expression, it would be just as valid to use "*var_name2". That is, both will give you the integer value stored in the memory referenced by the variable.

Once you take the "*" way from the pointer's identifier, then you are talking about the location in memory, not it's contents.

A little off topic from your original question, but hope it helps you read code better that uses pointers.

Something that really helps me understand pointers is to think of it as a type.

Code:

int n1; /* Integer */
int* n2; /* Pointer to integer */

The pointer is part of the type and goes on the left side.
If we remember that a pointer is a variable that holds an address, we would know that the name is just the address. By knowing the dereference principle (the one that says that to access the contents at location X), we should know that to get the value, just use *.

In fact, in C99 the compiler is required to optimize it as such, meaning that applying &* to a null pointer is fine. I don't know where my C90 copy is, but the C89 draft I have doesn't require a compiler to do this.

That's true (section 6.5.3.2, paragraphs 3, 4 and footnote 83), but unfortunately I too do not have a copy of the C90 standard to confirm that &*NULL results in undefined behaviour according to that set of rules.

In fact, in C99 the compiler is required to optimize it as such, meaning that applying &* to a null pointer is fine. I don't know where my C90 copy is, but the C89 draft I have doesn't require a compiler to do this.

That's true (section 6.5.3.2, paragraphs 3, 4 and footnote 83), but unfortunately I too do not have a copy of the C90 standard to confirm that &*NULL results in undefined behaviour according to that set of rules.

The two look almost the same. If you ignore the "*" and think of it as part of the name of the variable, then you can use them the same way. So, where ever you may use "var_name1" in an expression, it would be just as valid to use "*var_name2". That is, both will give you the integer value stored in the memory referenced by the variable.

Yes, that is what Stroustrup means when he states: "A ``typical C programmer'' writes ``int *p;'' and explains it ``*p is what is the int'' emphasizing syntax, and may point to the C (and C++) declaration grammar to argue for the correctness of the style. Indeed, the * binds to the name p in the grammar."

That said, there is an inconsistency when taking the syntax argument as is, since:

Code:

int var_name1 = x;

would generally become:

Code:

int *var_name2 = &x;

not:

Code:

int *var_name2 = x;

Consequently, I am influenced by my C++ background to talk about type instead of syntax, as in "A ``typical C++ programmer'' writes ``int* p;'' and explains it ``p is a pointer to an int'' emphasizing type. Indeed the type of p is int*."

Originally Posted by robwhit

That's a specific implementation of offsetof, right?

I think that would be undefined behavior if used in a program and not part of the implementation.

Yes, it is implementation dependand, but I know this implementation works in several different compilers, including gcc and MS VC.

Edit: In fact I don't think I've ever seen a DIFFERENT offsetof implementation (aside from the fact that I was paraphrasing the implementation itself), but I'm sure someone will come up with one that doesn't follow this pattern if we wait long enough.

--
Mats

EDIT:
Removed. Posted incorrect code, tried it out on my machine to verify, wreaked havoc. Oops