Technically, it's an expression of pointer type, but that might be too pedantic of me. I only keep it straight because of course the address of foo (that is, using & on foo) is an address.Originally Posted by Hodor
The problem is that &foo is not an address... it's a pointerGoing further, what does "address" mean anyway?
Hmm. Here I use & on foo and it's a pointer to int
Code:> g++ --std=c++11 test.cpp > ./a.out | c++filt -t int*Code:#include <typeinfo> #include <iostream> int main(void) { int foo; std::cout << typeid(&foo).name() << '\n'; return 0; }
Yes, and I don't disagree with anything the compiler might say. This is why I admitted that it was a pedantic point. However, a pointer's value is a memory address. An "expression of pointer type" is precisely what &foo is, just like (n + 1) is an integer expression. If there is anything that I really disagree with, it is that using the word address when discussing pointers is confusing or wrong.
I think we might think basically the same in that case
No, I'm pretty sure that we don't. Pointers don't store pointers, they store addresses. Saying that &foo is a pointer might actually "stop [someone from] saying address" but I don't really get where all the coy objection is going, at all.
I made my point though, so whatever.
Last edited by whiteflags; 01-08-2018 at 07:25 AM.
The point is that for some reason people find the incredibly simple subject of pointers confusing (it really is so simple that you'd have to be an imbecile to not understand them). Adding an extra term that is not even accurate in a modern computing environment simply confuses them further because the two different concepts are, at the end of the day, the same thing; an address *is* a pointer. Using the term "address of" is silly because it doesn't even appear anywhere -- except in naming the & operator -- the C Standard.
Edit: Next thing people will be saying that arguments to functions might be passed using "a stack" which is another example of something that is inaccurate (and another thing that the C standard doesn't mention at all because it's not necessary or accurate and might confuse the lemmings)
Edit: Oh, and I'm pretty sure we do. Because in my own mind I consider &foo to be the address of foo. I just don't tell new people that because it confuses them
Last edited by Hodor; 01-08-2018 at 06:33 PM.
I hesitate to say that it's even a fair point.
To be honest, I don't regard the C standard as a how-to manual, so it is unsurprising to me that it wouldn't necessarily include language like "address" or even "stack frame" very much. It's an unconvincing source to cite to avoid using those terms, unless you know that they aren't relevant to a specific platform or flavor of assembly. The C standard is light on many details, on purpose anyway. To say in so many words that addresses aren't mentioned in the standard means that addresses aren't really a thing is wrong. It means that you can explain a lot of language rules about pointers without explaining their reason for being or how they are used.
I could say the same about the stack frame example. They can exist. The only reason I have ever seen someone mention stack frames is because they are trying to explain function arguments, or return variables, coming from an assembly point of view. That is a much more practical matter than the C standard was ever written to address.
I agree with Hodor that the concept of pointers should be the least of a programmers problems when it comes to grasping concepts concerning the language. The hyped mystique surrounding them is almost comical.
What I suspect is that a good deal of aspiring coders have zero insight on how a computer works on a marginally deeper level and they may also get overwhelmed by the language's syntax required for correctly handling them.
'*', '&' and the way they're used seems to be too much of a hassle especially when former can have more complex usage patterns... enter function pointers(+pointer return values) and all goes down in flames even faster
I would go as far as having somebody learn the basics of assembler and only then return to pointers in C to remove some of the haze leading them astray.
