Why are pointers to inline functions allowed?

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.}