Reference type and pointer in disassembly

Question

Why reference types and pointers are same in compiled code?(You can see in third and fourth line). I tried to figure it out but apparently I could not achieve.

If a reference type variable must be initialized at declaration and can not be changed so is there any need to do indirection as in pointers?

int x = 10;

mov dword ptr [x],0Ah

int y = x;

mov eax,dword ptr [x]

mov dword ptr [y],eax

int &i = y;

lea eax,[y]

mov dword ptr [i],eax

int *p = &x;

lea eax,[x]

mov dword ptr [p],eax

p = &i;

mov eax,dword ptr [i]

mov dword ptr [p],eax

x = i;

mov eax,dword ptr [i]

mov ecx,dword ptr [eax]

mov dword ptr [x],ecx

Answer 1

A reference is represented internally as a pointer. It's the compiler that puts the restriction on initialization and non-reseatability.

If a reference type variable must be initialized at declaration and can not be changed so is there any need to do indirection as in pointers?

The only alternative is copying the value, which is not what a reference does. A reference acts similarly to a pointer: it holds onto the location of an object. The difference is that the reference acts like the object itself, instead of needing to be explicitly dereferenced.

Answer 2

If the referece is known by the compiler to always refer to a single particular object/item, then the compiler could certainly optimize away the indirection.

However, most references are in fact bound at runtime. Even if a particular instance of a reference can't be rebound, different executions of a particular scope or different instances of an object that contains reference members may run with the reference bound to a different object for each of those instances. Using indirection is a conventient way for the compiler to deal with this.

The situation where a reference is only ever bound to a single thing might be relatively infrequent enough that compilers might not look for the optimization - especially since it may be that the optimization wouldn't be a noticable gain in most cases.

Also, I suspect you're not turning on compiler optimizations - using your code and calling various functions with y and i and their addresses, a quick test in VC++ 2005 with optimizations on shows that the compiler is not implementing i as a pointer, but as a true alias for y (ie., whenever passing i or &i, the compiler uses the address of y directly).

If you're looking at the debug output of a compiler, it shouldn't surprise you that it always treats a reference as a pointer behind the scenes.

Answer 3

References are nothing but restricted pointers. The only difference is that they must point to an existing variable. You can get around that in C++, but it is much harder to miss with:

int& r = *(reinterpret_cast<int*>(0x0));

Of course this is undefined behavior!

So, basically they are implemented as pointers. They differ in usage in many places, eg. references are derefernced automatically when they come as r-values or l-values:

int x = 0;

int& r = x; // 1) no need to take the address of x like &x

r = r * x; // Manually: (*r) = (*r) * x

They provide a safer alternative to raw-pointers. Also, they come with much more elegant syntax than raw-pointers. Just imagine that you don't have references when overloading class operators.

In summary, they are restricted pointers, with a better/safer aliasing but with reduced functionality.

Answer 4

The C++ FAQ lite gives a good explanation for what you're seeing: http://www.parashift.com/c++-faq-lite/references.html

Essentially, in a nutshell, the compiler is essentially treating it like a pointer, it uses the address of the object and does the dereferencing work for you.

Answer 5

yep, references are just syntactic sugar for pointers (with restrictions appropriate for the new syntax). It also lets C++ appear to have copy-by-reference parameter passing, in contrast to C which only has copy-by-value (even pointer parameters)