What does "int& a = b" mean?

[doodle007]

I understand what both "int a = b" and "int* a = &b" mean, but is confused when I just saw "int& a = b".

My guess is both "a" and "b" are integers in this expression, but the address of "b" will be also assigned to be equal to the address of "a". The variable "a" remains to be an integer instead of a pointer.

Am I right on this? Thanks!

[mackabee]

int a = b is setting a's VALUE to b's VALUE
int* a = &b is setting a's VALUE to the ADDRESS of b
int& a = b is setting a's ADDRESS to b's ADDRESS (a is a reference to b)

[jsmith]

int& a = b;

binds the integer reference a to b. The address of the variable a is completely unmodified.
It simply means that all uses (references) of a actually use the value assigned to b.

[mackabee]

int& a = b is setting a's ADDRESS to b's ADDRESS (a is a reference to b)

That is exactly the same thing. Just a different way to represent the same idea.

[firedraco]

Except it's not. They are seperate.

What you are saying is that a IS b (which it isn't, they have different addresses). a just "references" b, meaning that if you change a, (at say, location x0110), then b (at say location x1111) will change too. a will always be at x0110, it won't change.

[lloydchristmas759]

Firedraco, can you please elaborate ?
a IS b, and they DO have the same address ( &a == &b ) !!

[Bazzy]

int &a = b will make a to have the same address as b
http://www.parashift.com/c++-faq-lite/references.html#faq-8.1

[jsmith]

They do not. You cannot, by standard, take the address of a reference variable.

The declaration int& a = b; allocates four bytes of memory (32-bit machine) and
stores in them the address of b. You cannot, through legitimate, portable means,
determine where in memory those four bytes were allocated.

[Disch]

! Am I misunderstanding?

I thought you could do this:

int a;
int& r = a;

assert(&r == &a);  // should always succeed 

Is this an incorrect assumption?

[jsmith]

I guess it's right. I dunno the wording of the standard OTOMH.

I gave a rather implementation-dependent answer above; Bazzy's reference is more general.

[mackabee]

Bazzy's reference is what I've said from the beginning.

int& a = b does not allocate 4 extra bytes (You described a pointer). It is only used as an alias for the compiler.

Create a function which sets a value using a and b and disassemble it.

[guestgulkan]

here you go mackabee - MSVC in debug mode:

  int a;
  int& r = a;

  r=2;

Dissassembly:

  2303:   int a;
  2304:   int& r = a;
004115A0 8D 45 E8         lea         eax,[ebp-18h] 
004115A3 89 45 DC         mov         dword ptr [ebp-24h],eax 
  2305: 
  2306:   r=2;
004115A6 8B 45 DC         mov         eax,dword ptr [ebp-24h] 
004115A9 C7 00 02 00 00 00 mov         dword ptr [eax],2 

[lloydchristmas759]

Of course a reference is handled similarly as a pointer by the compiler. Of course the compiler will allocate sizeof(void*) bytes (not necessarly 4!!) on the stack when one declares a reference. But that's irrelevant, and in fact, a programmer should not care about it.

The two (and only) relevant things about references are, if you have e.g. int& a = b :
- a IS b
- the address of a equals the address of b, i.e. &a == &b

[Disch]

Of course the compiler will allocate sizeof(void*) bytes (not necessarly 4!!) on the stack when one declares a reference.

I'm not so sure this is always the case. Compiler optimizations might remove the reference completely.

- a IS b

This is the best way to think about it, IMO.

[mackabee]

=-O guestgulkan has the proven me wrong T_T

Why would it act as a pointer and take up more memory when the compiler could just access the symbol globally?

*sinks back into a dark abyss*

[Disch]

The thing to realize here is that guestgulkan's example was in Debug build (ie: no optimizations). I'd wager an optimized build would have a different result.

[guestgulkan]

yeah, That'ts why I deliberately made sure I said it was in Debug mode.
I'm pretty sure that in the example I gave, the reference could be optmized out in release mode.

[onur]

Sometimes it cannot simply replace it.
Think of a function argument passed by reference.

void f(int& a)
{
  a = 5;
}

There's no way to simply replace the symbol a (except if the function is inlined).

If you use the reference only locally then it could be optimized away in some cases.

[Disch]

What if it's kept in a register the whole time? Then no variable allocation is needed at all, even if the function isn't inlined.

But anyway... sure, there will be instances where a pointer is allocated -- I didn't mean to say otherwise. In fact such instances are quite common.

My point is that you shouldn't think of references this way. IMO, the best way to conceptually look at it is that the reference is the var it refers to.