Getting the address of a reference variable

[bpark]

I was doing some work today and I realized that I was wrong about reference variables in C++. As we all know, C doesn't have this feature and it only has pointers.

#include <iostream.h>

int x = 5;
int *xPtr = &x;
int &xRef = x;

cout << xPtr << '\n';
// I thought this next line would spit out the address of xRef
cout  << &xRef << endl;

This will both print out the address of variable x. How do I get the address of reference variable xRef? More importantly, does reference variables get their own memory cell? I know for a fact that pointer variables(xPtr) get their own cell because &xPtr would print out the memory address of xPtr.

[Dolda2000]

Now I'm really against C++, but as far as I know, reference variables are some kind of "automatically dereferenced" pointers. That would lead me to think that just compiling xRef would lead to the same code as *xPtr, and in that case, &xRef would be &*xPtr, in deed yielding the address of x, in that it yields the reference to the dereferencing of xPtr, which is x. If you want the address of xRef, I guess that would &&xRef, but I don't know if the compiler accepts that. Try and see.

[bpark]

Dolda,

Going back to my code earlier

int x = 5;
int *xPtr = &x;
int &xRef = x;

cout << "Address of x via xPtr&#58; " << xPtr << endl;
cout << "Address of x via xRef&#58; " << &xRef << endl;

xPtr holds the address of x. If I did &xPtr, then it would give me the address of xPtr and NOT the address of x. This was why I was saying earlier that pointers get their own memory cell.
References are something like dereferenced pointers as you stated. &&xRef does not work on g++. I'm starting to think that reference variables may not have their own memory cell but then... I can't possibly seeing it working without it having it's own memory cell.

[Dolda2000]

I was saying that &*xPtr yields the address of x, not &xPtr. I was guessing that &&xRef wouldn't work, though, since &&*xPtr didn't compile with gcc (using normal C). References do get memory allocated to them, though, because, as you say, it wouldn't work otherwise. Maybe C++ doesn't allow you to get the address of a reference variable. It would seem strange, but it would go just in line with the rest of the things I don't like with C++.

[bpark]

I was saying that &*xPtr yields the address of x, not &xPtr.

Sorry about this confusion. I read it wrong. Looking at it now, there's really no point in doing &*xPtr to get the memory address of x since xPtr holds that info but syntax wise, it is absolutely correct.
I was just shocked to find out that &xRef would spit out the memory address of x. I guess I need to finally open that book by Stroustrup since I haven't even opened it.

[Dolda2000]

Yeah, the &*xPtr was just to be an analogy to what &xRef would compile into. Like I said, I've been trying to stay away from C++, but I'm assuming that reference variables are really just pointers, that are compiled so that they are always automatically dereferenced, ie. adding a * in front of them. In that case, parsing xRef would be the same as parsing *xPtr, and parsing &xRef would be the same as parsing &*xPtr. Of course, algebraically, they would negate each other and become just xPtr, but now C and C++ aren't true algebraic languages, and therefore &&*xPtr, which algebraically would be equivalent to &xPtr (which is correct), isn't correct since the compiler doesn't seem to support nested l-values. Therefore you can't do &&xRef either. I didn't know that until now, though. Does anyone know if the C standard says something about this?
Maybe there is an alternative method of double referencing xRef in C++; if you find something in that book of yours, please tell me, so that I'll know whether to further decrease my respect for C++ or not.

[bpark]

Dolda,

What is your native programming language? Mine was C++ and although I didn't learn anything at the University at Albany, I've learned C++ on my own. What language do u prefer to code in?

[Dolda2000]

C, of course, the one and only real language! Must you not love its unmatched clarity and power? And the way everything in it connects so closely to the hardware while still remaining platform independent? Man, I just can't stop drooling over it!
C++ on the other hand, I hold in quite low regard, for different reasons.
Actually, I learned programming in BASIC, and I kept doing that until I was 15, I think. Then I started extending BASIC with some C libraries, and then I switched to C completely. Mustn't you just love C?
I gotta quit... All this drooling isn't good for my keyboard...

[bpark]

Dolda,

Well, I have to agree with you on saying that C is a good language and I would normaly use C over C++ but the fact is, C doesn't support OOP. I've heard of something called objective C and I don't know hjow much potential it has but I've recently come to the conclusion that OOP is a very good programming technique.
Now I do have appreciation for C since I took a systems programming course but I have to say that structured programming is
A. Harder than OOP
B. Code cannot be reused with ease as in OOP
The professors at the university told us that C was faster than C++. I don't know how much of that is true but all I can say is I'd use C++ when I need to code something with classes and C when I don't.

[Dolda2000]

OOP is precisely the reason that I avoid C++. After all, the _only_ thing that C++ has over C is OOP. Sorry, but I really don't like OOP. As I see it, it's just useless wrapper code. (Do you know that many C++ "compilers" only generate C code which is passed directly to a C compiler?)
I must also say that I have no problems reusing code in C. What exactly is your problem with that?
The only advantage that I see with OOP is that the namespace is more hierarchical, which is a pretty huge advantage.

Sorry if I seem like I'm yelling at you. It's just that a strange fire is awakened in me every time I hear OOP being mentioned.