1

Code 1:

int main(){
   int a=1;
   int b=2;
   cout << "&a: "<<&a << endl;
}

Output 1:

&a: 0x22ff48

Code 2:

int main(){
   int a=1;
   int b=2;
   cout << "&a: "<<&a << endl;
   cout << "&b: "<<&b << endl;
}

Output 2:

&a: 0x22ff4c
&b: 0x22ff48


So My Question is why the address of the varibale a changed when I printed out the address of the varibale b ?

Matt
  • 22,721
  • 17
  • 71
  • 112
AlexDan
  • 3,203
  • 7
  • 30
  • 46

2 Answers2

7

When you didn't use b at all, the compiler probably removed it completely, so it didn't occupy any space.

When you took the address of b, that forced the compiler to allocate space for it.

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • 5
    In addition, it might not have eliminated it, but assigned it only to a register, since its address is never taken. – Dave S Dec 07 '12 at 21:21
  • @DaveS: Certainly possible as well. – Jerry Coffin Dec 07 '12 at 21:28
  • @JerryCoffin does this apply only if I access the address of variable b, because nothing changes in code1 if I print out the variable b, as if the compiler replaces b by it's value at compile time, and b didn't get allocated at all. – AlexDan Dec 07 '12 at 21:28
  • @AlexDan: Keep in mind we're only dealing in probabilities here. That said: yes, most compilers can eliminate the variable if it never varies. As DaveS pointed out, they can also assign them to registers if their address is never taken and there's nothing else more important to occupy the registers. – Jerry Coffin Dec 07 '12 at 21:31
5

Anyways, the OS is free to load the executable image at another (virtual) base address next time around.

What you are observing is undefined anyhow. The point is, even if no variables get optimized away, and the program doesn't get recompiled, it may yield different results each time.

It may be implementation defined, if you count the OS as part of the implementation

sehe
  • 374,641
  • 47
  • 450
  • 633
  • At least in a typical implementation, what's going to matter here isn't the load address of the executable image, but the base address of the stack (though, of course, that can vary as well). – Jerry Coffin Dec 07 '12 at 21:33
  • I would call it "unspecified" rather than "undefined". ;) – Yakk - Adam Nevraumont Dec 07 '12 at 23:09
  • @Yakk In fact, it _is_ undefined. The standard doesn't specify it should be defined by the implementation. (Heck, the standard doesn't even specify that `&a` should represent an _address_ (logical or physical). It's just ... a "pointer", which is an abstraction. The standard **does** specify that 'pointers' must be deterministically comparable, in a number of limited situations: http://stackoverflow.com/questions/9086372/how-to-compare-pointers/9086675#9086675) – sehe Dec 07 '12 at 23:13
  • Are you claiming that `int a=0;std::cout << &a;` could segfault on a conforming compiler? I'd expect the value you get to be unspecified by the standard, but I would doubt that the behavior of streaming a pointer out is "undefined behavior". – Yakk - Adam Nevraumont Dec 07 '12 at 23:25
  • 1
    @Yakk No. I didn't say that. The result will be implementation defined. But whether the result is the same on different runs of the identical code in "identical situation" (Heisenberg?) is _unspecified_ – sehe Dec 07 '12 at 23:53