std::pow implementation

[Richard Earnshaw]

> > > (*) Reasons why I'd accept inline not being honoured:
> 
> On Mon, Aug 04, 2003 at 12:53:09PM -0400, Robert Dewar wrote:
> > I would add
> > 
> > - doing the inlining as requested increases both the space and execution time
> > of the program, the former very substantially.
> 
> Nope.  It is appropriate for the compiler to do what the user said.  In
> C++, inline functions are for the most part so tiny that the inlined
> function takes up less space than the call.  Having the compiler compute
> metrics for all these functions in an effort to second-guess the
> programmer only slows the compiler down.

Not necessarily.  The benefit might be more than repaid in terms of less 
time spent in CSE if the function turned out to be large.

> If the user asks for very large functions to be inlined, the user loses.
> But the good news is that the fix is easy.

Think portability.  Having to change the code every time you compile on a 
different platform breaks the whole concept of using high-level languages 
to get away from the machine abstraction.

The issue here isn't what to do with really tiny functions, or even what 
to to with really enormous ones: it's entirely to do with the boundary 
between the two -- how does the compiler decide that it has crossed from 
one to the other?  A smart compiler can work that out based on its 
knowledge of the machine.  A dumb one can't.  Do we want gcc to be smart 
or dumb?

R.