0

while I was reading: Where does the reference variable gets stored

about the way references get saved in the memory, I came to the accepted answer which says:

On the other hand, if the reference is "persistent" or visible to other translation units (such as a data member or a global variable), it has to occupy some space and be stored somewhere. In that case, it will most likely be represented as a pointer, and code using it will be compiled to dereference that pointer.

could someone elaborate this point? why the compiler can't simply treat all uses of r as an alias for x[1], and access that int directly. (which is the case in the following function foo())

void foo()
{
  int x[4] = {0, 1, 2, 3};
  int &r = x[1];
  // more code
}
  • The quote was talking about uses such as `struct foo { int& fooRef; };` – Botje May 18 '20 at 12:31
  • It can and it probably will. References allow for a bit more leeway than an explicit use of pointers when it comes to optimizations – Big Temp May 18 '20 at 12:34
  • @Botje could you explain more? why in this example the compiler can't just treat it as a #define and needs to allocate memory for the alias lication? –  May 18 '20 at 12:38
  • How would that work if you receive a `foo` as parameter to a function call? Or dig one out of a `std::vector`? – Botje May 18 '20 at 12:42
  • "why in this example the compiler can't just treat it as a #define and needs to allocate memory for the alias lication?" because variable that reference would refer to is not known until runtime in this case. – Slava May 18 '20 at 12:46
  • The bit you're quoting is specifically *not* talking about the situation in the example. – molbdnilo May 18 '20 at 13:17

1 Answers1

0

why the compiler can't simply treat all uses of r as an alias for x[1]

Because in some cases x is not in scope, and the compiler has no knowledge of x. In such case, "alias of x[1]" is not meaningful.

Examples of such cases are mentioned in the quote:

(such as a data member or a global variable)

eerorika
  • 232,697
  • 12
  • 197
  • 326
  • but a global variable is always in scope –  May 18 '20 at 12:55
  • plus why does it even matter if x in scope or not, the compiler is smart enough and can tell that this r refers to that x in some location... –  May 18 '20 at 12:57
  • @john1998 global variable is in scope. But the object that the global variable refers to is not necessarily in scope. It might not even be a variable. – eerorika May 18 '20 at 13:01
  • @john1998 The program has to know exactly what that location is. "It's in *some* location" is not useful for the compiler. – eerorika May 18 '20 at 13:03
  • @john1998 I think the crucial part that you are missing is that compiler only compiles single `.cpp` file at a time. When it finishes, it forgets everything hat it has done and moves to the next one. When all `.cpp` files are compiled to assembly, linker takes in and links all the pieces into single executable. This means compiler has very limited knowledge about certain things and it has to rely on linker to make sense out of it. – Yksisarvinen May 18 '20 at 13:06
  • 1
    @john1998 Consider this declaration in a header: `extern int& ri;` (global reference). If this reference is defined in a single translation unit and used in another, a compiler cannot know when compiling the latter to which is the reference bound. – Daniel Langr May 18 '20 at 13:07