40

As the title itself mentions - why are pointer to a reference illegal, while the reverse is legal in C++?

Enlico
  • 23,259
  • 6
  • 48
  • 102
Mahesh
  • 34,573
  • 20
  • 89
  • 115
  • 1
    Looks like someone took my words seriously from here http://stackoverflow.com/questions/4632528/what-does-class-cls-mean-in-cs-function-definition .... that's good :D – Nawaz Jan 08 '11 at 06:59
  • 1
    Anyway, +1 for the good question. even I want to know the rationale! – Nawaz Jan 08 '11 at 07:00
  • 1
    @Nawaz: Your guess is correct. – Mahesh Jan 08 '11 at 07:04

5 Answers5

51

A pointer needs to point to an object. A reference is not an object.

If you have a reference r, once it is initialized, any time you use r you are actually using the object to which the reference refers.

Because of this, you can't take the address of a reference to be able to get a pointer to it in the first place. Consider the following code:

int x;
int& rx = x;

int* px = ℞

In the last line, &rx takes the address of the object referred to by rx, so it's exactly the same as if you had said &x.

James McNellis
  • 348,265
  • 75
  • 913
  • 977
  • 10
    This is the most relevant answer so far. Since it is impossible to take the address of a reference, what would be the point of having a pointer to it? The only value you could initialize such pointer to is NULL. – Sergei Tachenov Jan 08 '11 at 07:39
  • 3
    +0.5 for this line *"you can't take the address of a reference to be able to get a pointer to it in the first place."* ...And +0.5 for this *"&rx takes the address of the object referred to by rx, so it's exactly the same as if you had said &x."* .... beautiful explanation! – Nawaz Jan 08 '11 at 08:25
  • 1
    Thanks for this. I need to do exactly what you said - get a pointer to the original object through a reference. – James May 05 '17 at 17:58
17

The high-level concept that references implement is just another name for an existing object. You can have a pointer to an object (or function), but you can't have a pointer to an object's name. For this very reason, the idea of a pointer to a reference makes no sense. In other words, references are immaterial, in general case they simply do not exist in memory. They don't exist as something that can be pointed to.

It is true that in many cases in practice references do occupy memory (and are implemented as pointers in disguise). But that just an implementation detail specific to some particular contexts. In general case references do not occupy memory, as is explicitly stated in the language specification which immediately follows from the language specification.

AnT stands with Russia
  • 312,472
  • 42
  • 525
  • 765
  • 1
    @AndreyT : can you quote the relevant section(s) from the language specification? – Nawaz Jan 08 '11 at 07:15
  • Also it would be helpful if given a downloadable link of the entire C++ language specification. I googled but couldn't find one. – Mahesh Jan 08 '11 at 07:26
  • 1
    @Mahesh : It is not available for free. – Prasoon Saurav Jan 08 '11 at 07:28
  • 6
    @Nawaz : 8.3.2/3 `It is unspecified whether or not a reference requires storage ` – Prasoon Saurav Jan 08 '11 at 07:30
  • @Prasoon Saurav : Could you post the online purchasable link of specification. – Mahesh Jan 08 '11 at 07:46
  • @Mahesh : There are pre-finalization drafts available which is good enough for our purposes. Just google "C++ Standard - ANSI ISO IEC 14882 2003". You'll get links to downloadable PDFs. Most likely the first link! – Nawaz Jan 08 '11 at 07:52
  • @Mahesh : Also, you might have some query regarding Standard and all, So have a look at this topic : http://stackoverflow.com/questions/4522352/the-c-standard-book-recommendation .... and see the accepted answer there! – Nawaz Jan 08 '11 at 07:56
  • 4
    @Prasoon Saurav: In my copy of the standard, 8.3.2/5 explicitly says `There shall be no references to references, no arrays of references, and no pointers to references`. – Blastfurnace Jan 08 '11 at 08:47
  • 1
    @Prasoon : that means, AndreyT's statement *In general case references do not occupy memory, as is explicitly stated in the language specification.* is incorrect, as the specification doesn't say so! – Nawaz Jan 08 '11 at 10:36
  • 1
    @Mahesh: You can download the current draft N3225 which is linked from the [Wikipedia article](http://en.wikipedia.org/wiki/C%2B%2B0x) on C++0x. – fredoverflow Jan 08 '11 at 10:47
  • 1
    @Nawaz : Read the complete paragraph and specially "in general". :) – Prasoon Saurav Jan 08 '11 at 10:53
  • @Prasoon : but the specification doesn't say anything of that sort, whether that is "in general" or "rarely", or "in very specific cases". unspecified means only unspecified, right? It doesn't imply "in general". – Nawaz Jan 08 '11 at 10:58
  • Yeah right but contradicting AndreyT's statement means "a lot" :). It is indeed unspecified. – Prasoon Saurav Jan 08 '11 at 11:04
  • 3
    @Nawaz: Apparently we have different understanding of what "in general case" mean. The standard indeed says that it is unspecified whether references occupy storage. This means that one can say that "in general case, references occupy no storage" and that "in general case, references occupy storage". Both statements are true. You simply use the one that is relevant in your specific context. – AnT stands with Russia Jan 08 '11 at 11:08
  • @Prasoon : I don't understand why you used the term "but" in your statement. – Nawaz Jan 08 '11 at 11:10
  • @AndreyT : *This means that one can say that "in general case, references occupy no storage" and that "in general case, references occupy storage". Both statements are true.* ... then please write both statements, and see how it looks. – Nawaz Jan 08 '11 at 11:14
  • @Nawaz : Never mind. AndreyT has responded to your comment. :) – Prasoon Saurav Jan 08 '11 at 11:15
  • @AndreyT : *You simply use the one that is relevant in your specific context*... No, this is confirmation bias; you select what suits your reasoning, ignoring the other statement! – Nawaz Jan 08 '11 at 11:16
  • @Prasoon : By the way, I downvoted it. And you know the reason. I think the last statement is incorrect, and the overall explanation is not so convincing. After all, it's supported by an incorrect statement! – Nawaz Jan 08 '11 at 11:20
  • 1
    @FredOverflow: I don't think that N3225 is very useful for any purpose other than considering new features for C++0x. If you read it as though it describes the current standard, and/or describes what current C++ implementations do, then you will get a *lot* of things wrong (even when considering what current implementations do with C++0x extensions enabled, there will be differences due to incomplete support and changing drafts). On this particular point we happen to know that C++0x and C++03 are the same, so you'd get away with using the draft, but that's begging the question. – Steve Jessop Jan 08 '11 at 12:22
  • @Mahesh: the final version of the C++03 standard is called "ISO/IEC 14882:2003(E)". Try searching for that. – Steve Jessop Jan 08 '11 at 12:25
  • @Nawaz: You apparently are implying that these statements are mutually exclusive. They are not, in my understanding of the concept of "general case". One can say "not all kids are nice" and "not all kids are naughty". It is easy to see that both are true, even though the key word is changed to its exact opposite. Again, you use the one that applies in your context. – AnT stands with Russia Jan 08 '11 at 17:06
  • @Nawaz: Saying that "in general case, A is true" means that you should expect that A might be true, even if the probability of A is small. It means: plan for the worst. You should expect references to occupy storage in contexts where you'd prefer them not to. You should expect references to occupy no storage in contexts where you'd prefer them to occupy it. – AnT stands with Russia Jan 08 '11 at 17:09
  • @Nawaz: So, *"in general case, references occupy no storage"* means *"some reference **might** occupy no storage, so when you want to assume that they do occupy storage, force yourself to think they they **never** do"*. At the same time *"in general case, references occupy storage"* means *"some reference **might** occupy storage, so when you want to assume that they don't occupy storage, force yourself to think that they **always** do"*. – AnT stands with Russia Jan 08 '11 at 17:15
  • 4
    @AndreyT : *One can say "not all kids are nice" and "not all kids are naughty"*.... Trying using "in general" here... "in general, muslims are terrorists".. and "in general, muslims are not terrorists"... "in general, indians are idiots" and "in general, indians are not idiots"..."in general, you are wrong" and "in general, you are not wrong"... these **are** contradicting statements. Period! – Nawaz Jan 08 '11 at 17:38
  • 4
    @AndreyT : You said *" **In general** case references do not occupy memory, as is **explicitly stated** in the language specification."*... which is quite misleading. If it should make sense here, then it should make sense everywhere whenever the specification uses the term "unspecified"..... I repeat the specification says *"It is **unspecified** whether or not a reference requires storage"* which **cannot** be translated into "in general, references do not occupy memory". – Nawaz Jan 08 '11 at 17:51
  • @Nawaz: You are trying to confuse formal mathematical logic with the logic used in common everyday speech - a rather well-known fallacy. Yes, and I repeat, when the therm "in general" used in formal mathematical context it describes the statement that might/is likely to be true but not necessarily always true. This is the accepted usage of the formal term "general". A classic example for the field of computational geometry (for just one example) would be "a set of points in *general* position", which means that no three points lie on the same line. – AnT stands with Russia Jan 08 '11 at 18:19
  • @AndreyT: you're uselessly arguing... I wonder how these two statements *"in general, you're wrong"* and *"in general, you're not wrong"* can peacefully coexist in a **rational** mind!!! – Nawaz Jan 08 '11 at 18:31
  • @Nawaz: Well, the difficulties you are having with it are pretty much the same difficulties unprepared people have with understanding the concepts of Quantification in mathematical logic, like quantifiers "for all"/"far any" and "exists". The [non-existent] contradiction your have been insisting upon is the same non-existent contradiction mentioned in the "Natural language" section of this Wikipedia article: http://en.wikipedia.org/wiki/Quantification. – AnT stands with Russia Jan 08 '11 at 20:22
  • @AndreyT: Just tell me if all compilers implement references that occupy memory, do you think it would contradict what the specification says? Of course, not. But your statement will be completely wrong, since what you said is not equivalent to what specification says. – Nawaz Jan 08 '11 at 20:59
  • @AndreyT: Can we read "in general" wherever the specification says "unspecified"? Yes or No? – Nawaz Jan 08 '11 at 21:01
  • @AndreyT: there is nothing wrong in admitting that you made an incorrect statement, by the way. Don't argue uselessly. After all, you've edited your post after so many arguments! And the new/modified statement is still wrong! – Nawaz Jan 08 '11 at 21:03
  • @Nawaz: Er... What? If all compilers implemented references as objects in memory, it would not contradict the specification. Yet, it still would be an implementation detail, which has no importance at language level. In the appropriate context, at language level it would still be correct to say that in general case references occupy no memory. – AnT stands with Russia Jan 08 '11 at 22:21
  • @Nawaz: As for your "Yes or No" question: Yes, we can turn an "unspecified" statement into the corresponding "in general..." statement every time. I already provided a very detailed explanation in my comments above. The fact that you ignored it clearly indicates that you are simply trying to drown the debate in mindless repetition. – AnT stands with Russia Jan 08 '11 at 22:22
  • @Nawaz: There's nothing wrong with it when you feel that concepts of formal mathematical logic are more difficult to understand than the concepts of natural everyday logic. You are not the first one that has these difficulties. However, is cases like that it is always better to ask for an explanation (even though it might feel "uncool"), instead of trying to steer the debate into a confrontation, secretly hoping that the explanation you desire will pop up by itself. – AnT stands with Russia Jan 08 '11 at 22:27
  • @AndreyT : Where the specification says *"at language level it would still be correct to say that in general case references occupy no memory"*???? – Nawaz Jan 08 '11 at 22:31
  • @AndreyT : When you use "in general", it means you're preferring one option over all others. But the specification does NOT say anything of that sort. Unspecified means Unspecified. People should learn to avoid twisting the meaning of English words. – Nawaz Jan 08 '11 at 22:38
5

What would be the difference between a pointer to a reference (to the object) and a pointer to the actual object? The reference cannot be changed to refer to another object. Just use a regular pointer to the object in question.

On the other hand, a reference to a pointer, like any other reference, gives you a modifiable handle to a particular variable. It happens to be a pointer in this case.

Potatoswatter
  • 134,909
  • 25
  • 265
  • 421
1

Because a reference is not a thing that can be pointed at, which in turn is because it does not actually have to be represented anywhere in memory. References exist to give alternate names to already-existing things. You can get a pointer to the renamed thing, but that is a pointer to a value, not a pointer to a reference.

Karl Knechtel
  • 62,466
  • 11
  • 102
  • 153
0

Suppose "int *&X" is legal, because reference is just another name of an object, the expression is equal to "int *X" and is not useful.

John
  • 1
  • 2