CODEWITHSUNDEEP
c++
codebuff
codebuff

Reputation: 39

Why is the address of a variable defined inside a loop unchanged on each iteration?

for(int i=0; i<10;i++){
    int j = i;
    cout << &j << endl;
}

This will output the same address of j in each iteration. I also noticed the same behavior in C. Shouldn't it be a different address for different iteration ?
In python different address is printed, couldn't verify it in java

for i in range(10):
    j = i
    print(hex(id(j)))

c++ -v on my system returns this 

Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.2.0-8ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.2.0 (Ubuntu 7.2.0-8ubuntu3)

Upvotes: 2

Views: 351

Answers (3)

dbush
dbush

Reputation: 223972

The address of a local variable is an implementation detail of the compiler.

When a local comes into scope like this, the compiler might reuse the same address it had before, or it might not. You shouldn't depend on it either way.

In practice, with optimizations turned off, it's most likely simpler for the compiler to use the same address each time. In fact, if function a were to call function b multiple times, the local variables of function b will most likely be in the same place each time the function is called.

But again, this is an implementation detail. There's no guarantee this will be the case across different compilers, or on the same compiler with different optimization settings.

Upvotes: 8

Galik
Galik

Reputation: 48615

The address is implementation defined. However, the variable will be created on a stack-like memory structure because of the requirement for objects to deconstruct in reverse order from their constructing.

So it is not allocating random pieces of memory from a heap (or the free store), it is likely re-using the same part of the stack memory structure each time round the loop.

If you think about it, at the beginning of each loop it creates the variable and then destroys it at the end of the loop -freeing up the memory it just occupied. It is not a surprise it then re-creates the object in the same place next time the loop starts.

Upvotes: 0

StoryTeller - Unslander Monica
StoryTeller - Unslander Monica

Reputation: 170084

shouldn't it be a different address for different iteration ?

There's no requirement for it to be this way. In fact, on a common implementation where a local variable is located on a functions call frame (on the so called call stack), it's rather easy for the address to be unchanging. It's just reusing the same space, relative to the start of the frame.

In python different address is printed

Because the implementation in Python is different. In each iteration i is reference for a different object in the range. It's not the same storage taking on a different object and value.

Upvotes: 0

Related Questions