In this case, I see no reason why not, according to the as-if rule, the compiler should only imitate the observed behavior of the program. A quick experiment using godbolt :
#include <tuple> #include <cstdio> void func( int x1, int x2,int x3, int x4) { std::tuple<int,int,int,int> t{x1,x2,x3,x4}; int a, b, c, d; // in real context these names would be meaningful std::tie(a, b, c, d) = t; printf( "%d %d %d %d\n", a, b, c, d ) ; }
shows that gcc really optimizes it:
func(int, int, int, int): movl %ecx, %r8d xorl %eax, %eax movl %edx, %ecx movl %esi, %edx movl %edi, %esi movl $.LC0, %edi jmp printf
On the other hand, if you used the address t and printed it out, now we are observing the behavior based on t existing ( see it lives ):
printf( "%p\n", static_cast<void*>(&t) );
and we see that gcc no longer optimizes t :
movl %esi, 12(%rsp) leaq 16(%rsp), %rsi movd 12(%rsp), %xmm1 movl %edi, 12(%rsp) movl $.LC0, %edi movd 12(%rsp), %xmm2 movl %ecx, 12(%rsp) movd 12(%rsp), %xmm0 movl %edx, 12(%rsp) movd 12(%rsp), %xmm3 punpckldq %xmm2, %xmm1 punpckldq %xmm3, %xmm0 punpcklqdq %xmm1, %xmm0
At the end of the day you need to see what the compiler creates and profiles your code, in more complex cases this may surprise you. Just because the compiler is allowed to perform certain optimizations does not mean that this will happen. I looked at more complex cases where the compiler does not do what I would expect with std::tuple . godbolt is a very useful tool here, I cannot calculate how many optimization assumptions I used that were overcome by connecting simple examples to godbolt.
Note. I usually use printf in these examples because iostreams generates a lot of code that interferes with this example.