On 02/08/13 10:32, Jonathan M Davis wrote: > On Friday, February 08, 2013 09:30:41 Artur Skawina wrote: >> On 02/08/13 01:33, Jonathan M Davis wrote: >>> Hmmm. I wouldn't have thought that you could get the function pointer at >>> compiler time. Regardless, you lose any possibility of inlining the >>> function call, which is the main problem AFAIK, though I don't know if >>> they would have been an option in the case of dup anyway. >> >> It doesn't affect inlining. (Obviously, that's compiler dependent, but >> there's no reason why it should and indeed does not w/ gdc) > > How could it not affect inlining? You're using a pointer to a function > instead > of the function itself, so it can't be inlined. Do you mean that dup in
"&f" is an expression that evaluates to a constant, known at compile time (modulo link-/run-time relocation/offset fixups, but that's irrelevant here). "(&f)()" is trivially recognizable (for the compiler) as equivalent to "f()". Not unlike the "int i; auto j = *&i, k = i;" case where you can expect the compiler to optimize away the address-of and dereferencing, and evaluate the first expression just like the second one. > of the function itself, so it can't be inlined. Do you mean that dup in > particular doens't get inlined even when called directly? That's quite > possible, but in the general case, using a function pointer rather than > calling a function directly risks taking a small efficiency hit due to the > fact > that the function can no longer be inlined. It makes no difference. I actually checked, because I was wondering if the reinterpret cast wasn't confusing the compiler - it doesn't and inlining happens as it should even with that cast in the mix. artur
