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

[Jorge Rivera]

Can anyone here suggest any reason at all why the following expression would
be false?:
sizeof(BankAcco untInfoPointers ) == sizeof(BankAcco untInfoReferenc es)

Because sizeof(---Pointers) has to be the size of a number (16,32,64
bits). sizeof(---References) could well result in giving you the size
of the object it refers to.

This isn't an ignorant rhetorical question, I'm genuinely interested in a
possible reason, other than "'cause the Standard doesn't says it has to be".

But that is the reason you have to weight the most. If the standard
does not guarantee this, and there is a clever way of implementing
reference behavior that is not based on pointers, all your underlying
assumptions will be lost.

If yu had a car before the 80s, you would have probably assumed that the
only way to pump gas is through a carburator. Nowadays, this is rarely
true. What I mean is, the fact that references are implemented as
pointers today does not guarantee that it always will, and you MUST
realize this.

Stop arguing. What's the point?

Jorge L.

[Karl Heinz Buchegger]

Mabden wrote:

"Jorge Rivera" <jo*****@roches ter.rr.com> wrote in message
news:mH******** ***********@twi ster.nyroc.rr.c om...

Can anyone here suggest any reason at all why the following expression would be false?:
sizeof(BankAcco untInfoPointers ) == sizeof(BankAcco untInfoReferenc es)

Because sizeof(---Pointers) has to be the size of a number (16,32,64
bits). sizeof(---References) could well result in giving you the size
of the object it refers to.

This isn't an ignorant rhetorical question, I'm genuinely interested in a possible reason, other than "'cause the Standard doesn't says it has to be".

But that is the reason you have to weight the most. If the standard
does not guarantee this, and there is a clever way of implementing
reference behavior that is not based on pointers, all your underlying
assumptions will be lost.

If yu had a car before the 80s, you would have probably assumed that the
only way to pump gas is through a carburator. Nowadays, this is rarely
true. What I mean is, the fact that references are implemented as
pointers today does not guarantee that it always will, and you MUST
realize this.

Ah. So, altho they probably ARE const pointer right now,

They CAN be.
But the ARE NOT.

A reference may exist in the symbol table of your compiler
only.
When your compiler encounters this piece of code:

int main()
{
int i;
int& j;

it creates 2 entries in its symbol table, one for i, one for j.
The point is: The compiler marks j as beeing a reference to i.
Now when the compiler compiles

j = 5;

It looks up j in its internal symabol table and figures out that
j is an alias for i. So the compiler modifies the statement
to read

i = 5;

and compiles that instead.

In the final exacutable, j doesn't even show up and this has nothing
to do with some optimizations. It's just a consequence of: a reference
is another name to an already existing object.

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

[Karl Heinz Buchegger]

JKop wrote:

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 ?

References.

Pointers is what they are, and on a 32-Bit Memory Model platform, sizeof
(Jeep) will be 64 Bits, which proves my point.

Which proves exactly nothing.
An example is not a proof.

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

[Old Wolf]

JKop <NU**@NULL.NULL > 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.
I should hope not, since they would be wrong.
Look man, several people with many years of practical C++ experience
have told you that you are wrong. Maybe you should start listening to them?
struct Jeep
{
std::Vector& a;
std::Vector& b;
};

int main(void)
{
Vector j;
Vector k;

Jeep jeep = {j, k};
} Then explain the above. If it's just another name for a variable, then what
the hell are a and b ?
'a' and 'b' are other names for variables, as you say.

If you consider this slightly modified (and compilable) example:

struct Jeep
{
std::vector<int > &a;
Jeep(std::vecto r &a_): a(a_) {}
};

int main()
{
std::vector<int > v;
Jeep j(v);

j.a.push_back(1 0);
v.push_back(12) ;
}

"j.a" and "v" mean exactly the same thing. If you picture the memory
location of the vector in your mind, think of it as having two labels
"j.a" and "v". These two terms are completely interchangeable , in
any expression. If you think about it for a moment, you would realise
that the same is not true of pointers.

Pointers is what they are, and on a 32-Bit Memory Model platform, sizeof
(Jeep) will be 64 Bits, which proves my point.

It would be difficult for the compiler to maintain a list of which
label refers to which object, by any means other than storing the
address of that object with that label. Implementations use addresses
internally when remembering what references are bound to.

Implementation details do not "prove your point". (On one of my
systems, sizeof(int) is 2. Does this prove that ints have 16 bits?)

It's good that you have something in mind that gives you a better
handle on references. But you should bear in mind that this is
an imperfect description, and you will become confused in future
when you encounter problems with it. For example, as you pointed
out yourself,

int Monkey() { return 42; }
int main()
{
int const &k = Monkey();
std::cout << k << std::endl;
return 0;
}

How would you write that with const pointers? What is &k?

It's like the "dump-truck" analogy for electricity (each electron is
loaded up with power, and as it passes through the bulb, it dumps all
its power so the bulb glows). Seems like a good idea, but is actually
totally wrong, and worse than useless.

[JKop]

int Monkey() { return 42; }
int main()
{
int const &k = Monkey();
std::cout << k << std::endl;
return 0;
}

You're accessing unallocated memory there - the temporary no longer
exists.
-JKop

[JKop]

John Harrison posted:

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

int Monkey(void) { return 42; }
void Parrot(int* pBeak)
{

std:: cout << *pBeak;

}
int main(void)
{

int* k;
Parrot( &( *k = Monkey() ) );
system("PAUSE") ;

}

I love it!

If anyone could post something from the Standard regarding the lifetime of
temporaries, I'd appreciate it. As far as I know, the above is valid, ie.
DEFINED BEHAVIOUR!
-JKop

[Rob Williscroft]

JKop wrote in news:bi******** *********@news. indigo.ie in comp.lang.c++:

John Harrison posted:

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

int Monkey(void) { return 42; }
void Parrot(int* pBeak)
{

std:: cout << *pBeak;

}
int main(void)
{

int* k;

k points where ?

Parrot( &( *k = Monkey() ) );
You've just writen (*k =) the value 42 to some random location.

This is Undefined Behavior.


system("PAUSE") ;

}

I love it!
Whats to love ?

If anyone could post something from the Standard regarding the
http://www.techstreet.com/cgi-bin/de...uct_id=1143945
lifetime of temporaries, I'd appreciate it. As far as I know, the
above is valid, ie. DEFINED BEHAVIOUR!

No its UB.
Rob.
--
http://www.victim-prime.dsl.pipex.com/

[Karl Heinz Buchegger]

JKop wrote:

int Monkey() { return 42; }
int main()
{
int const &k = Monkey();
std::cout << k << std::endl;
return 0;
}

You're accessing unallocated memory there - the temporary no longer
exists.

He is not.
JKop you have posted since a few days and some of your posts
are really good. But your knowledge is weak. There are a few
regulars in this group you should listen to. You can only learn
from them.

As why the above is not accessing unallocated memory:
When a temporary is bound to a reference, the lifetime
of the temporary is also bound to the lifetime of the
reference. The temporary lives as long as the reference
lives.

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

[Karl Heinz Buchegger]

JKop wrote:

John Harrison posted:

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

int Monkey(void) { return 42; }

void Parrot(int* pBeak)
{

std:: cout << *pBeak;

}

int main(void)
{

int* k;
Parrot( &( *k = Monkey() ) );
system("PAUSE") ;

}

I love it!

If anyone could post something from the Standard regarding the lifetime of
temporaries, I'd appreciate it. As far as I know, the above is valid, ie.
DEFINED BEHAVIOUR!

Take more care!
The above is undefined behaviour. Where does k point to when you
dereference it. Just because it compiles and runs at your system
doesn't mean it is correct.

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

[Mabden]

"Karl Heinz Buchegger" <kb******@gasca d.at> wrote in message
news:40******** *******@gascad. at...

JKop wrote:

John Harrison posted:

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

int Monkey(void) { return 42; }

void Parrot(int* pBeak)
{

std:: cout << *pBeak;

}

int main(void)
{

int* k;
Parrot( &( *k = Monkey() ) );
system("PAUSE") ;

}

I love it!

If anyone could post something from the Standard regarding the lifetime of temporaries, I'd appreciate it. As far as I know, the above is valid, ie. DEFINED BEHAVIOUR!

Take more care!
The above is undefined behaviour. Where does k point to when you
dereference it. Just because it compiles and runs at your system
doesn't mean it is correct.

Sorry for the quote-to-comment ratio, but WTF?!!

Can you guys figure it out and post the actual truth about how this works? I
don't know enough to figure it out and you are getting less helpful as you
post snipettes. Somebody please summarize the argument and explain how
pointers (or const pointer) and references differ in the Real World (tm).

--
Mabden