REFERENCES REVEALED

[JKop]

I understand variables/objects and pointer variables perfectly:

int X = 5;

int* pX = &X;

*pX = 4;

int** ppX = &pX:

**ppX = 3;
---

I know exactly how references "behave", but I want to know how they actually
work!

For instance, take the following function:

void Repot(unsigned int* pX)
{
*pX = 45U;
}
The caller will do the following:

int main(void)
{
unsigned int X = 17U;

Repot(&X);
}
Obviously one could rewrite the above code as:
void Repot(unsigned int& X)
{
X = 45U;
}
int main(void)
{
unsigned int X = 17;

Repot(X);
}
But what I want to know is what's actually going on under the hood. One
quick little side note here though before I continue: When I first learned
about references, I detested them, I thought they were extremely stupid. One
may argue that they're easier to use, just as one may argue that an
automatic transmission car is easier to driver, but long story short, I
prefer manual transmission and detest references. So anyway, I could find no
justification for the introduction of references into C++, other than to
make operator overloading for classes possible. I was pleasantly amused when
I heard a quote from Bjarne himself stating that the reason he introduced
references into C++ was to enable operator overloading for classes. Fair
enough, and although in my opinion it is heavily contrived, it works! Just
for clarification, here's what I hate so much about references: Before, when
calling a function, you could specify "X" to indicate the value stored in
the variable, and you could specify "&X" to indicate the memory address of
the variable. With references, this is no longer so. (Yes, I am aware that
one can determine from the function prototype whether or not it's a
reference... I don't like it).

So anyway, how does the compiler deal with references? Does it simply treat
them as short-hand? Would the compiler turn my preceeding code (written
using references) back into pointers? ie. would it simply stick in the "*"
and "&" where appropriate? If the answer to this is Yes, then I pressume
that both samples of code would compile identically and hence allocate the
same amount of memory. (That is, the use of a reference does not supress the
need to have another variable within which to store the address of another
variable, ie. a pointer variable). If this is so, everything is fine and
dandy and I understand references, regardless of whether I like them. If
this is NOT so, I am at a loss! Before, I used to just think of it as
follows: If a function has a reference as a parameter, then you can think of
it as the scope of the variable being extended to the function which has
been called. This concept worked fine for me until I came across functions
whose return type was a reference. This is where my brain started
stuttering. Take the function prototype:

unsigned int& TeachFarmAnimal s(void);

When you call the above function, what exactly are you getting back as a
return type?!! Are you simply receiving a pointer, and is the compiler just
sticking in the "*" and "&" for you where appropriate?
In summation:

Are references just pointers without the need to include "&" and "*", and is
the compiler just handling the "&" and "*" for you in the background?
-JKop

[Jack Klein]

On Sun, 16 May 2004 19:19:54 GMT, JKop <NU**@NULL.NULL > wrote in
comp.lang.c++:

I understand variables/objects and pointer variables perfectly:

int X = 5;

int* pX = &X;

*pX = 4;

int** ppX = &pX:

**ppX = 3;
---

I know exactly how references "behave", but I want to know how they actually
work!
They work very well, thank you.

[snip]
But what I want to know is what's actually going on under the hood.

Unfortunately, you are asking in the wrong place. The C++ standard
does not specify what goes on "under the hood". The standard defines
the interface to the programmer and the behavior when used correctly.
It places no requirements at all on the implementation as to how it
delivers the correct results. Nor is it necessary to for one to know
the details to write a correct C++ program.

If you want to understand how a specific compiler does these things,
study the object code it generates. If you want to discuss the
possible mechanisms in general, try news:comp.compi lers.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[John Harrison]

"JKop" <NU**@NULL.NULL > wrote in message
news:u9******** **********@news .indigo.ie...

I understand variables/objects and pointer variables perfectly:

int X = 5;

int* pX = &X;

*pX = 4;

int** ppX = &pX:

**ppX = 3;
---

I know exactly how references "behave", but I want to know how they actually work!

For instance, take the following function:

void Repot(unsigned int* pX)
{
*pX = 45U;
}
The caller will do the following:

int main(void)
{
unsigned int X = 17U;

Repot(&X);
}
Obviously one could rewrite the above code as:
void Repot(unsigned int& X)
{
X = 45U;
}
int main(void)
{
unsigned int X = 17;

Repot(X);
}
But what I want to know is what's actually going on under the hood. One
quick little side note here though before I continue: When I first learned
about references, I detested them, I thought they were extremely stupid. One may argue that they're easier to use, just as one may argue that an
automatic transmission car is easier to driver, but long story short, I
prefer manual transmission and detest references. So anyway, I could find no justification for the introduction of references into C++, other than to
make operator overloading for classes possible. I was pleasantly amused when I heard a quote from Bjarne himself stating that the reason he introduced
references into C++ was to enable operator overloading for classes. Fair
enough, and although in my opinion it is heavily contrived, it works! Just
for clarification, here's what I hate so much about references: Before, when calling a function, you could specify "X" to indicate the value stored in
the variable, and you could specify "&X" to indicate the memory address of
the variable. With references, this is no longer so. (Yes, I am aware that
one can determine from the function prototype whether or not it's a
reference... I don't like it).
You're missing out on two important aspect of references, one aesthetic, one
practical.

From the aesthetic point of view the chief difference between pointers and
references is that references always refer to the same object, unline
pointers. So if you need to refer to some object, and that reference (in the
general sense) is never going to refer to another object during its lifetime
you should consider using a reference (in the C++ sense) because it better
expresses what you are doing.

From the practical point of view there is the fact that a const reference
can bind to a temporary, something a pointer cannot do. Consider

class X;

void f1(const X*);
void f2(X);
void f3(const X&);
X g();

f1(&g()); // illegal

X t = g();
f1(&t); // ugly temp variable, extra copy

f2(g()); // extra copy, may or may not be optimised by compiler

f3(g()); // perfect


So anyway, how does the compiler deal with references? Does it simply treat them as short-hand? Would the compiler turn my preceeding code (written
using references) back into pointers? ie. would it simply stick in the "*"
and "&" where appropriate?

Almost certainly, so certain am I that I've always assumed this to be the
case on every compiler I've ever used, and haven't actually bothered to
check. The only way to be sure would be to have a look at the machine code
your compiler generates.

john

[JKop]

I finally understand reference variables perfectly!! It's the way that they
were described to me that had me all confused. The books I've learned from
have never just stated plainly:

A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
It's like a const pointer variable, ie. you must initialize it upon
declaration:

int m = 5;

int* const pM = &m;

int& j = m;
Andt the second and final difference is that you treat it like a normal
variable, ie. you don't use the asterisk to access its data. And again, like
a normal variable, if you get the address of it, you get back an "int*", as
opposed to an "int**". It's so clear in my mind now. I fully understand:

Car& Porsche = *(new Car);

delete &Porsche;
and it's much more beautiful than:

Car* pPorsche = new Car;

delete pPorsche;
That is, you can work with a "Car", and not with a "Car*"!!
And similarly, when a function returns a reference:

int& GetApe(void);
It's returning a const pointer that you can treat as an "int" as opposed to
an "int*".
John Harrison, you said that an reference can also bind to a temporary, and
that's cool too, but just for clarity, so can a pointer. Consider the
following tested code:
long double Monkey(void)
{
return 87.343;
}

void Chocolate(long double* pTermite)
{
*pTermite = 56.242;

std::cout << *pTermite;
}

int main(void)
{
long double k;

Chocolate(&(k = Monkey()));

system("PAUSE") ;
return 0;
}

The temporary in the above is valid, right?
-JKop

[JKop]

JKop posted:

John Harrison, you said that an reference can also bind to a temporary,
and that's cool too, but just for clarity, so can a pointer. Consider
the following tested code:
long double Monkey(void)
{
return 87.343;
}

void Chocolate(long double* pTermite)
{
*pTermite = 56.242;

std::cout << *pTermite;
}

int main(void)
{
long double k;

Chocolate(&(k = Monkey()));

system("PAUSE") ;
return 0;
}

The temporary in the above is valid, right?

I TOTALLY dropped the ball there!! I'm making a copy of the temporary via:

k = Monkey();
Duh!!!
I see what you're getting at, John Harrison, that you simply can't get the
address of a temporary, ie:

&(Monkey())

The above doesn't compile. Yet, a reference *will* get the address!!
-JKop

[osmium]

JKop writes:

I finally understand reference variables perfectly!! It's the way that they were described to me that had me all confused. The books I've learned from
have never just stated plainly:

A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
A reference variable is just a pointer variable.

What so you call a variable that can't be changed in your world?

[JKop]

osmium posted:

JKop writes:

I finally understand reference variables perfectly!! It's the way that
they were described to me that had me all confused. The books I've
learned from have never just stated plainly:

A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
A reference variable is just a pointer variable.

What so you call a variable that can't be changed in your world?

Ignoring your grammar...
I was given vague descriptions like so:
A reference is used so a function can edit the variable passed to it:

void Monkey(int& j)
{
j = 5;
}
It never actually just stated that a reference is just a const pointer
variable that's treated like a domestic non-pointer variable.

-JKop

[Karl Heinz Buchegger]

JKop wrote:

I finally understand reference variables perfectly!! It's the way that they
were described to me that had me all confused. The books I've learned from
have never just stated plainly:

A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
A reference variable is just a pointer variable.

Wrong.
A reference is just another name for a variable.

Your compiler might use a pointer internally to represent it, but
it need not. Nevertheless the thinking model of a 'hidden pointer'
is a good one. But there is a difference between a mental model
and what things really are. References are alternative names.
--
Karl Heinz Buchegger
kb******@gascad .at

[Karl Heinz Buchegger]

Karl Heinz Buchegger wrote:

JKop wrote:

I finally understand reference variables perfectly!! It's the way that they
were described to me that had me all confused. The books I've learned from
have never just stated plainly:

A reference variable is just a pointer variable.
A reference variable is just a pointer variable.
A reference variable is just a pointer variable.

Wrong.
A reference is just another name for a variable.

Also wrong:

A reference is just another name for an object (it need not be a variable)

--
Karl Heinz Buchegger
kb******@gascad .at

[JKop]

Karl Heinz Buchegger posted:

Wrong.
A reference is just another name for a variable.

Your compiler might use a pointer internally to represent it, but
it need not. Nevertheless the thinking model of a 'hidden pointer'
is a good one. But there is a difference between a mental model
and what things really are. References are alternative names.

struct Jeep
{
std::Vector& a;
std::Vector& b;
};
Then explain the above. If it's just another name for a variable, then what
the hell are a and b ?

Pointers is what they are, and on a 32-Bit Memory Model platform, sizeof
(Jeep) will be 64 Bits, which proves my point.
int main(void)
{
Vector j;
Vector k;

Jeep jeep = {j, k};
}