pointer and reference maybe similar at assembly level

from Parashit (http://www.parashift.com/c++-faq-lite/references.html)



Reference:
An alias (an alternate name) for an object.

References are frequently used for pass-by-reference:

void swap(int& i, int& j)
{
int tmp = i;
i = j;
j = tmp;
}

int main()
{
int x, y;
...
swap(x,y);
...
}
Here i and j are aliases for main's x and y respectively. In other words, i is x not a pointer to x, nor a copy of x, but x itself. Anything you do to i gets done to x, and vice versa.

OK. That's how you should think of references as a programmer. Now, at the risk of confusing you by giving you a different perspective, here's how references are implemented. Underneath it all, a reference i to object x is typically the machine address of the object x. But when the programmer says i++, the compiler generates code that increments x. In particular, the address bits that the compiler uses to find x are not changed. A C programmer will think of this as if you used the C style pass-by-pointer, with the syntactic variant of (1) moving the & from the caller into the callee, and (2) eliminating the *s. In other words, a C programmer will think of i as a macro for (*p), where p is a pointer to x (e.g., the compiler automatically dereferences the underlying pointer; i++ is changed to (*p)++; i = 7 is automatically changed to *p = 7).

Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.

The key difference between pointers and references is that there is no such thing like null reference. A reference is always identifies a valid object in the memory.

:)

A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.
However, it is not just the object indicated by the type !

Consider:

class B
{
//...
};

class D : public B
{
//...
};

void f(const B& b)
{
// b could actually be an instance of D !
}

void g()
{
D d;

f(d);
}

:)

However, it is not just the object indicated by the type
Right but why would I write such a code?

Earlier you wrote this

class D
{
//...
};

not this

class D : public B
{
//...
};

:)

Earlier you wrote this
Yeah, sorry about that.
:)

My earlier code would obviously never have compiled.
:o

Can you explain it to me in code.

There is nothing to explain it using code, you already ahve seen the assembly code for both. All I am saying is that the reference types are always implemented as const pointers, the pointers that never change.

Nothing in C++ spec says how references are to be implemented.
Is that also the case for pointers ? Or does the C++ spec say how a pointer is implemented ?

Is that also the case for pointers ? Or does the C++ spec say how a pointer is implemented ?

As I said in my preivious post the C++ language represents an abstraction. It's defined by a standard. It would be a mistake to standardize how different language constructs must be implemented. It would limit the compiler constructors in their quest for ever more efficient implementations and adaptations to changing hardware.

I fully agree with post 14 and I find it hard to believe that someone who seemingly is an experienced programmer can show such a complete lack of insight as in post 10.

from Parashit (http://www.parashift.com/c++-faq-lite/references.html)



The key difference between pointers and references is that there is no such thing like null reference. A reference is always identifies a valid object in the memory.

:)

Wrong. Considering the following.

#include <iostream>

class Test
{
public:
Test() : value(0) {}
virtual ~Test() {}
int value;
};

Test * GetNewTest()
{
Test * pTest = NULL;

// pTest = new Test;

return pTest;
}

int main(int _argc,char * _argv[])
{
Test & testRef = *GetNewTest();

testRef.value = 100; // access violation

return 0;
}

Valid C++, yet it has a logic error.

Would you be happy with the statement:

"The references are often implemented in the same way const pointers are."

They pretty much have to be. Consider the following.

extern int Value; // Value is in another .cpp file

int & ValueRef = Value;
int & ValueRef2 = Value;

void Function(int value)
{
ValueRef = value;
}

int main(int argc,char * argv[])
{
Function(1200);

if (Value == 1200)
{
// Do something
}

return 0;
}

return 0;

The only other VALID way of representing a reference would be for the compiler to just treat it as an alias to the actual value. HOWEVER, passing by reference means you can change the value itself, and in order to do so with every function call, is to make references the same as a constant pointer. The reason being, is because not every module (*.DLL) can know the address of a variable in the executable that it links against. (no extern)

Not to mention, that the variable passed in a reference can be a dynamic object, and also could be a sub object of another object.

THEY HAVE to be implemented as constant pointers. Do you see why?

Yes this statement shows an understanding of the difference between the C++ language itself and possible implementations.

No... They HAVE to be implemented as pointers because of the way the language is defined versus machine architecture. READ MY ABOVE POST...

The language does not define how they have to be implemented, but... The architecture does.

In an example where the reference is in the same CPP file, is a global reference to a global variable (or a local in a function) then the reference CAN be treated as an alias, but not when passing to functions.

Valid C++, yet it has a logic error.
I think that the access violation is not the error. The error is dereferencing a null pointer. Consequently, an outright "wrong" targets the "always identifies a valid object" but glosses over the correctness of "difference between pointers and references is that there is no such thing like null reference", making it seem as if there is such a thing as a null reference (especially since you quoted that portion).

Or does the C++ spec say how a pointer is implemented ?
...A valid value of an object pointer type represents either the address of a byte in memory or a null pointer. If an object of type T is located at an address A, a pointer of type cv T* whose value is the address A is said to point to that object, regardless of how the value was obtained. ... The value representation of pointer types is implementation-defined. Pointers to cv-qualified and cv-unqualified versions of layout-compatible types shall have the same value representation and alignment requirements. :wave: :wave: :wave:

The layout requirements listed in your post shows exactly what I am talking about.Since you approve, here's what the text says about references
3 It is unspecified whether or not a reference requires storage.
4 ... A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the object obtained by dereferencing a null pointer, which causes undefined behavior. ... end note ]

It stated that whether a reference requires storage or not is undefined, means it goes to logic. And logic states what I said. The implementation requirements require that in most places, a reference would require storage (therefore implemented as a const pointer) and in the instances where it does not, is what I described before.

So without reading the standard, I just basically told you why it is defined that way.

I do not need to read the standard to know why it's implemented that way. It's common sense.

Dereferencing the NULL pointer is not the problem.

The access violation is caused by the assignment of a value through that reference to memory address 0.

The actual cause is using a reference to an invalid memory address.

The code that tries to access byte index 4 (pointer size is 4 on 32 bit platform, vtable before the int) from the base (reference points at memory address 0) causes the access violation.

NOBODY every checks on the NULL pointer dereference in implementation of the compiler, because to be compliant with the standard (since this is declared to be illegal) would require an exception to be thrown of type std::unexpected.

We all know that exception handling is a big overhead. And LOTS of C++ code dereferences pointers.

Not to mention, a reference can point at any memory address (if it has storage) just like a pointer. NULL isn't necessarily the only invalid address.

When dereferencing a pointer as well, since it's a POINTER to an object... That means that the reference will require storage (unless that pointer is declared in scope) and if it requires storage it's a const pointer, period in implementation.

The syntax is only defining the way that a reference gets initialized.

Think of references to pointers. This makes it more clear.

void * pVariable = malloc(512);
void * & pVariableRef = pVariable;

pVariable will point at the memory returned from malloc. Now, pVariableRef is a reference to pVariable. Therefore, pVariableRef is technically a void ** const.

Now, the reference is guaranteed to point here at a valid void *, HOWEVER... How references act does not mean the memory pointed at by pVariable is valid.

void * pVariable = malloc(512);
void * & pVariableRef = pVariable;
pVariableRef = NULL; // memory leak!

Even though pVariableRef (if not in the same scope as pVariable) is technically a void ** const, which means it's basically like this.

void ** const pVariablePointer = &pVariable;
*pVariablePointer = NULL; // MEMORY LEAK

But... the below code has no leak.

#include <iostream>
#include <cstdlib>

void * pVariable;
void * & pVariableRef = pVariable;
void ** const pVariablePointer = &pVariable;

int main(int,char **)
{
pVariable = malloc(512);

free(pVariableRef);

*pVariablePointer = 0;

return 0;
}

In the case of a reference to a pointer (which in fact, is the same as a reference to any object, in this case the object is a "void *") we see for a fact that a reference IS NOT the object itself.

To get an idea of what I mean, declare in a header file a function that returns a void * that was malloc()'ed. Then implement it in another. In main(), then declare a reference to a void * that is returned from that function, then pass it to free. Check the assembly code, you will see that it is deferencing a pointer to a pointer so it can pass it to free.

UNLESS, the compiler optimizes it in the way that it is treated as a pointer.

From the perspective of what happens, then yes, the access violation is the "problem". However, I am looking at it from the perspective of the programmer: the mistake must lie with the attempt to dereference the null pointer, not the attempt to use testRef. This is why I call the access violation the symptom of the problem: when you sneeze, the problem is that you are sneezing, since that is happening and affects you. However, the problem that the doctor would solve is your illness, and this in turn would remove the symptoms of the illness.

Indeed, hence the standard mentions the null pointer/reference case "in particular". In general, "a reference shall be initialized to refer to a valid object or function".

The best way to handle it, is to just go with common sense.

In a well formed program, a reference will always point to a valid object.

But then again, in a well formed program, there are no bugs at all. Unless the bugs are in DLL that the program depends on. :rolleyes:

See my prior post about references to pointers, you'll see more of what I am trying to say.

Then see this code.

#include <iostream>

int Value;

#include <pshpack1.h>

class Test
{
public:
Test() : TestVar(Value)
{
}
virtual ~Test()
{
}
private:
int & TestVar;
};

#include <poppack.h>

int main(int,char **)
{
std::cout << "MinGW implementation says sizeof(Test) is: " << sizeof(Test) << std::endl;

if (sizeof(Test) == 8)
{
std::cout << "The reference requires storage. It is not the object itself." << std::endl;
}

return 0;
}

On my test of MinGW (3.4.4 - With CodeBlocks) it reports storage required. Why? Because even though the constructor sets it a global variable, storage is required for 2 reasons.

A) Exposing this type to other compile units, requires that the address of the variable it points to is stored.

B) A different constructor could define it to be another variable.

To bring this back to the context: ashukasama stated that "a reference (...) always identifies a valid object in the memory", and you disputed this statement. The statement that "the reference is guaranteed to point here at a valid void *" agrees with ashukasama's assertion. That the memory pointed at by pVariable may not be valid does not matter, since the object in question is pVariable, not what pVariable points to.

I am not too concerned with this "reference might not be implemented as const pointer" business myself, but to be fair all this exercise would have done is to show that on the reader's implementation references are implemented as const pointers. This line of discussion does not seem very fruitful in my opinion, since conceptually we can still view references as aliases, and compilers may perform their optimisations.


Then read the code above in my edit of my last post, and then the comments below it. That should convince you.

What is your point?

My point is, with the topic of the discussion.

And the fact that understanding an implementation of the compiler, by understanding the logic in doing so, is a 'fruitful' discussion.

Understanding why a reference would require storage, makes you understand better in general.

Interesting to note however... Requiring storage...

#include <iostream>

int Value;

#include <pshpack1.h>

class Test
{
public:
Test() : TestVar(Value)
{
}
Test(int dummy) : TestVar(*new int(dummy))
{
}
virtual ~Test()
{
delete &TestVar;
}
int & TestVar;
};

#include <poppack.h>

int main(int,char **)
{
std::cout << "MinGW implementation says sizeof(Test) is: " << sizeof(Test) << std::endl;

if (sizeof(Test) == 8)
{
std::cout << "The reference requires storage. It is not the object itself." << std::endl;
}

Test myObject(100);

std::cout << myObject.TestVar << std::endl;

myObject.TestVar = 1001;

std::cout << myObject.TestVar << std::endl;

return 0;
}

Isn't the value returned from new int a temporary? Yet, this causes no access violation, and the sizeof the object is indeed 8. :confused:

The answer to that is simple. In neither constructor is it an alias to an integer. In this case the reference is acting as a pointer. Not an object itself. It has to. In the case of #1:

The constructor is pointing at a global variable, and requires to be a pointer due to the fact that another constructor could set it to be something else.

Dereferencing a pointer returned from new actually just gives you the address that new returns in this instance.

#include <iostream>

struct A
{
double x,y,z;
};

int main()
{
A a;

A & ra = a;

const A * pa = &a;

std::cout << "sizeof(pa) = " << sizeof(pa) << "\n";

std::cout << "sizeof(ra) = " << sizeof(ra) << "\n";

return 0;
}

References can either be an alias, or a pointer to the object.

Please state the section in the C++ standard that says this.

Please state the section in the C++ standard that says this.

I am not reading the C++ Standard. I am going by logic, and in code examples.

Logic states that if you pass to a function by reference (const ObjectType & ref) since it can point at any object that you pass of that type (or derived) that they can be implemented as pointers.

The text above, tells you why to think of it as one. The problem when thinking about them as pointers, is because pointers are considered types themselves. So a reference when in storage is a data_const_volatile_modifier Type * const. Which is fine in that sense, because the value of the pointer cannot change, the same as the reference.

There is no difference between.

*pPointerToValue = 100;
RefToValue = 100;

That simple.

Aliasing is done when a reference is referencing an object that is in the same scope, and the compiler knows that it does not require storage.

The very fact in the standard about 'storage' is enough to back that up. Just stating whether or not references require storage, reflects common sense.

In terms of common sense...

A person can only be in one place at one time...

So...

If PersonA lives at a certain address, in that same scope (within that house), you can call them by their nickname. (ALIAS)

However...

When trying to tell PersonA to do something, or change some of their data, while PersonA is at Address 3500, when you are at address 4800... You have to send a message to address 3500. (disguised pointer)

I am not reading the C++ Standard. I am going by logic, and in code examples.

Logic states that if you pass to a function by reference (const ObjectType & ref) since it can point at any object that you pass of that type (or derived) that they can be implemented as pointers.

The text above, tells you why to think of it as one. The problem when thinking about them as pointers, is because pointers are considered types themselves. So a reference when in storage is a data_const_volatile_modifier Type * const. Which is fine in that sense, because the value of the pointer cannot change, the same as the reference.

There is no difference between.

*pPointerToValue = 100;
RefToValue = 100;

That simple.

Aliasing is done when a reference is referencing an object that is in the same scope, and the compiler knows that it does not require storage.

The very fact in the standard about 'storage' is enough to back that up. Just stating whether or not references require storage, reflects common sense.

In terms of common sense...

A person can only be in one place at one time...

So...

If PersonA lives at a certain address, in that same scope (within that house), you can call them by their nickname. (ALIAS)

However...

When trying to tell PersonA to do something, or change some of their data, while PersonA is at Address 3500, when you are at address 4800... You have to send a message to address 3500. (disguised pointer)

I am not sure but this is what i think. If you think as a c programmer , "&" means addressof operator.
when you create reference for example

int main()
{
int i = 90;
int &ref = i;
}

the statement int &ref = i means
address_of ref = address_of i
so now ref has addressof i .
That is how references are made.
Pointers have there own memory location, and they contain address of another variable .

It means the same thing in C++. The "&" symbol is used for two things in C++: The "address-of", just like in 'C', and something that is not in 'C', and that is it used to define references.

int main()
{
int i;
int *pi = &i; // address-of. This is *not* a reference
}

The use of "&" in C++ to mean the traditional address-of, and for reference usage has nothing to do with each other -- they are two different contexts used by the same symbol.

It's like trying to see a commonality in the "*" symbol -- it is used for multiplication, and for dereferencing a pointer -- one operation has nothing to do with the other.

Regards,

Paul McKenzie

hello Paul,
your right , i know that c address -of operator is also valid in c++ as address-of operator. The compiler sees the context of the statement and decides what to do. What i want to say is that the inventor of c++ did a could trick to implement references , when you say something like
int &ref = i;
is implemented as address-of ref = address-of i;
Second thing i emailed this question to the inventor of c++ , he said that the machine code of most references is an address same as pointers.