make a nothrow call a throwing function

[Artur Skawina]

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