pointers address

Pages: 12
There are circumstances where they're interchangable words; there are circumstances where they're not.


Exactly. Note I am not speaking about every case, but I am specifically speaking about pointer rvalues, which can often by called pointers instead of addresses.
The value of an expression with pointer type represents an address. The value category of the expression has nothing to do with it.

That's the formal interpretation. Check [basic.compound].

Programmers occasionally speak colloquially, because precision isn't required.

Maybe better (briefer) terminology would help programmers to speak precisely with less overhead.
As I have repeatedly said, I don't care about 'formal interpretation.' I'm not a textbook. My point was SPECIFICALLY for OP to understand what pointers represent. And to do so, I treated pointers just like we treat every other primitive data type. I agree they are indeed addresses.
Last edited on
"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less." "The question is," said Alice, "whether you can make words mean so many different things." "The question is," said Humpty Dumpty, "which is to be master—that's all."
As I have repeatedly said, I don't care about 'formal interpretation.' I'm not a textbook.

Right, it's not always so practical to talk (write) like a textbook. I'm just commenting that it would be nice if there weren't so many usually-irrelevant and esoteric distinctions between variables, values, expressions, objects, identifiers, pointers, and addresses, and that maybe introducing new, less verbose terminology would help the precision of a typical discussion.
Last edited on
By the way, who is reporting all of my comments lol
Calling a pointer an address is about the same as calling a giraffe an elephant. Without a doubt, they both have 4 legs but that's about all. Claiming their equivalence in the interests of assisting budding zoo-keepers is a flimsy argument to say the least.
@againtry
That analogy doesn't really work. At this point, you aren't really addressing my argument or debunking any of the points I made, but are just repeating the notion that it's not correct.

I mean, if we're going with animal analogies here, it's kind of like a pigeon that shits on a chessboard and the two players, knocks over all the pieces, declares itself the winner, and flies away.

But, to drive the point home:
1
2
3
4
5
6
7
8
9
#include <iomanip>
#include <iostream>
#include <type_traits>

int main()
{
    int var{};
    std::cout << std::boolalpha << std::is_same_v<decltype(&var), int*>;
}
true


From this, we can deduce the type of &var is the same as int*. Meaning &var's type is int* (int-pointer). Emphasis on the POINTER. Yes, its an address, but its type is a pointer type. Colloquially, we can refer to &var as a pointer, because it's type is and always will be an int-pointer. Just like 5.0 is a double and 5.0f is a float.

I rest my case.
Last edited on
I understand your position exactly. @dutch, in all his characteristic colorfulness was nevertheless correct.

You recently referred to the C++20 draft standard. Perhaps you could revisit it and read that the definition of a pointer very simple and very clear, just as @dutch wrote.

And, for the sake of zoological correctness, a rhinoceros and giraffe, as dissimilar as they are, shit over pigeons every time.

There is no rest for the wicked ;)

I think the discussion right now for something this simple is just beating a dead horse. I don't know what Againtry has posted, but it's safe to just ignore him.
"I think" now there's a surprise coming from mr lame voice-over.


The address-of operator returns a pointer

It’s worth noting that the address-of operator (&) doesn’t return the address of its operand as a literal. Instead, it returns a pointer containing the address of the operand, whose type is derived from the argument (e.g. taking the address of an int will return the address in an int pointer).

Perhaps you could revisit it and read that the definition of a pointer


I am well aware of its definition. As I have said, I don't care about the textbook definition. My position is one based on the way we treat other data types. But let's agree to disagree, friend.
I am well aware of its definition. As I have said, I don't care about the textbook definition. My position is one based on the way we treat other data types.
Classic!
Topic archived. No new replies allowed.
Pages: 12