std::pow implementation

[Richard Earnshaw]

> | Profiling doesn't help if the answer comes back as "sometimes" (function 
> | foo's use of bar is best inlined, function wibble's use of bar is best not 
> | inlined).
> 
> The cases where it most does not help is when the compiler decides it
> knows better and goes on using his own programmed logic.

You've lost me... If the compiler can decide that not inlining things is 
better, how does that differ from what we have now?

> | > | With Gaby's suggested interpretation, the compiler has *no* choice; it 
> | > | must obey the inlining constraint because the programmer always knows 
> | > | better...  Even when prepared to admit that he doesn't.
> | > 
> | > That assertion is wrong.
> | 
> | Which bit of it?  It's what I understand you to be suggesting.
> 
> As I've repeatedly said, there are pathological cases where the
> compiler simply cannot inline.  Secondly, I'm saying that the
> compiler does not always know better than the programmer.  And in fact,
> the programmer most of the time declares "inline" on purpose.  
> 
> Transmuting the meaning of "inline" is creating more fear, uncertainty
> and doubt than we needed.

Suggesting that a programmer must only use inline when they are convinced 
that better code will always result (ie that using inline when it may only 
sometimes produce better code is "dangerous") sounds even more like 
spreading FUD to me.  You're going to get people saying "Never use inline, 
it can make your code worse".

R.