I have two questions:
1) Why are pointers to inline functions allowed in C++?
I have read that the code of inline functions just gets copied to the function call statement and there is no compile-time memory allocation in inline functions. So why can a pointer exist to an inline function, given that there is no fixed memory address for inline functions?
2) Consider the code below:
inline void func()
{
int n=0;
cout<<(&n);
}
Should it not print different values of the address of n each time func() is called?
[Because I think that every time inline function code is copied, reallocation of the local variables must be done (whereas in the case of normal functions, reinitialisation takes place)]
I am a beginner and I asked this question for the sake of my concept strengthening. Please correct me if I am wrong anywhere.
1) Why pointers to inline functions are allowed in c++?
Because inline functions are functions just like any other, and pointing to them is one of the things that you can do with functions. Inline functions just aren't special in this regard.
I have read that code of inline functions just get copied to the function calling statement and there is no compile time memory allocations in inline functions.
You (and perhaps the material you've read) have mixed two related and similarly named concepts.
An inline function is defined in all translation units that use it, while a non-inline function is defined in one translation unit only as required by the one definition rule. That is what an inline declaration of a function means; it relaxes the one definition rule, but also gives the additional requirement of being defined in all translation units that use it (which would not have been possible if the odr wasn't relaxed).
Inline expansion (or inlining) is an optimization, where a function call is avoided by copying the called function into the frame of the caller. A function call can be expanded inline, whether the function has been declared inline or not. And a function that has been declared inline is not necessarily expanded inline.
However, a function can not be expanded inline in a translation unit where it is not defined (unless link time optimization performs the expansion). Therefore the requirement of being defined in all TUs that the inline declaration allows, also makes possible the inline expansion of the function by allowing the function to be defined in all TUs that invoke it. But the optimization is not guaranteed.
2) Should it not print different values of address of n each time func() is called?
Inline expansion does cause the local variables to be located in the frame of the caller, yes. But their location will differ regardless of expansion if the calls originate from separate frames.
There is typically a regular non-expanded version generated of any function that has been expanded inline. If the address of a function is taken, it will point to that non-expanded function. If the compiler can prove that all calls to a function are inlined, the compiler might choose to not provide the non-expanded version at all. This requires that the function has internal linkage, and taking the address of the function typically makes such proof very difficult, or impossible.
The inline keyword was originally a hint to the compiler that you the programmer think this function is a candidate for inlining - the compiler is not required to honor this.
In modern usage, it has little to nothing to do with inlining at all - modern compilers freely inline (or not) functions "behind you back", these form part of the optimization techniques.
Code transformations (including inlining) are done under the "as-if" rule in C++, which basically means that the compiler can transform the code as it wants to, so long as the execution is "as-if" the original code was executed as written. This rule fuels optimizations in C++.
That said, once an address is taken of a function, it is required to exist (i.e. the address is required to be valid). This may mean that it is no longer inlined, but could still be (the optimizer will apply the appropriate analysis).
So why can a pointer exist to a inline function, given that there is no fixed memory address of inline functions?
No, it is only a hint and largely relates to linkage and not actual inlining. This fuels, what is arguably the main current usage, defining functions in header files.
Should it not print different values of address of n each time func() is called?
It might, the n is a local variable, based on the stack location when the function executes. That said, the function inline, it relates to linkage, the linker will merge the functions over the translation units.
As noted in the comments;
... that if the example is changed to static int n, then every call to the function must print a constant value (in a single program run of course) ... and that is true whether or not the code is inlined or not.
This is, again, the effect of the linkage requirement on the local variable n.
You read old material. The main reason for using inline nowdays is to allow function bodies in header files. Use of inline keyword with a function signals to the linker that all instances of the function across translation units can be combined; having a non-inline function in a header that is included from multiple units causes undefined behaviour due to a One Definition Rule violation.
C++17 also adds inline variables, which have the same property that the variable can be defined in a header, and all definitions are combined by the linker instead of causing ODR violation.
The stuff you are talking about with "code getting copied to the calling function" is called inlining and is independent of the inline keyword. The compiler will decide whether or not to do this, based on optimization settings, for non-inline functions as well as inline functions.
Inline functions are not always inlined. It just signals that the programmer would like this function to be inlined. The compiler is allowed to inline any function, regarless of whether inline keyword was used or not.
If the address of function is used, the function is most likely not inlined in the final executable, at least in GCC:
When a function is both inline and static, if all calls to the function are integrated into the caller, and the function's address is never used, then the function's own assembler code is never referenced.
GCC documentation
Apart from the already said point that an inline function need not actually be inlined (and many functions without inline are inlined by modern compilers), it's also entirely conceivable to inline a call through a function pointer. Example:
#include <iostream>
int foo(int (*fun)(int), int x) {
return fun(x);
}
int succ(int n) {
return n+1;
}
int main() {
int c=0;
for (int i=0; i<10000; ++i) {
c += foo(succ, i);
}
std::cout << c << std::endl;
}
Here, foo(succ, i) could as a whole be inlined to just i+1. And indeed that seems to happen†: g++ -O3 -S produces code for the foo and succ functions
_Z3fooPFiiEi:
.LFB998:
.cfi_startproc
movq %rdi, %rax
movl %esi, %edi
jmp *%rax
.cfi_endproc
.LFE998:
.size _Z3fooPFiiEi, .-_Z3fooPFiiEi
.p2align 4,,15
.globl _Z4succi
.type _Z4succi, @function
_Z4succi:
.LFB999:
.cfi_startproc
leal 1(%rdi), %eax
ret
.cfi_endproc
But then it generates code for main which never refers to either of these, instead just includes a new specialised _GLOBAL__sub_I__Z3fooPFiiEi:
.LFE999:
.size _Z4succi, .-_Z4succi
.section .text.startup,"ax",@progbits
.p2align 4,,15
.globl main
.type main, @function
main:
.LFB1000:
.cfi_startproc
movdqa .LC1(%rip), %xmm4
xorl %eax, %eax
pxor %xmm1, %xmm1
movdqa .LC0(%rip), %xmm0
movdqa .LC2(%rip), %xmm3
jmp .L5
.p2align 4,,10
.p2align 3
.L8:
movdqa %xmm2, %xmm0
.L5:
movdqa %xmm0, %xmm2
addl $1, %eax
paddd %xmm3, %xmm0
cmpl $2500, %eax
paddd %xmm0, %xmm1
paddd %xmm4, %xmm2
jne .L8
movdqa %xmm1, %xmm5
subq $24, %rsp
.cfi_def_cfa_offset 32
movl $_ZSt4cout, %edi
psrldq $8, %xmm5
paddd %xmm5, %xmm1
movdqa %xmm1, %xmm6
psrldq $4, %xmm6
paddd %xmm6, %xmm1
movdqa %xmm1, %xmm7
movd %xmm7, 12(%rsp)
movl 12(%rsp), %esi
call _ZNSolsEi
movq %rax, %rdi
call _ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
xorl %eax, %eax
addq $24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1000:
.size main, .-main
.p2align 4,,15
.type _GLOBAL__sub_I__Z3fooPFiiEi, @function
_GLOBAL__sub_I__Z3fooPFiiEi:
.LFB1007:
.cfi_startproc
subq $8, %rsp
.cfi_def_cfa_offset 16
movl $_ZStL8__ioinit, %edi
call _ZNSt8ios_base4InitC1Ev
movl $__dso_handle, %edx
movl $_ZStL8__ioinit, %esi
movl $_ZNSt8ios_base4InitD1Ev, %edi
addq $8, %rsp
.cfi_def_cfa_offset 8
jmp __cxa_atexit
.cfi_endproc
.LFE1007:
.size _GLOBAL__sub_I__Z3fooPFiiEi, .-_GLOBAL__sub_I__Z3fooPFiiEi
.section .init_array,"aw"
.align 8
.quad _GLOBAL__sub_I__Z3fooPFiiEi
.local _ZStL8__ioinit
.comm _ZStL8__ioinit,1,1
So in this case the actual program does not even contain a function pointer pointing to succ – the compiler has found out that this pointer would always refer to the same function anyway, and was therefore able to eliminate the entire thing without changing the behaviour. This can improve performance a lot, when you often call small functions through function pointers. Which is quite a widespread technique in functional languages; compilers for languages like O'Caml and Haskell make great use of this kind of optimisation.
†Disclaimer: my assembly skills are close to nonexistent. I might well be talking rubbish here.
