Re: std::pow implementation

[Richard Earnshaw <rearnsha at arm dot com>]

> Richard Earnshaw wrote:
> > This is talking specifically about *very small* functions ("one or two 
> > assignments").  It says nothing about what happens if the programmer 
> > decides to put a 2000 line monstrosity in the middle of a class definition 
> > (which would be legal, if somewhat stupid).  A practical compiler 
> > eventually has to say "enough is enough", or it is likely to crash, run 
> > out of memory or whatever.
> 
> I do not want my freedom limited by the stupidity of others. If someone 
> explicitly inlines a 2000-line function, let them; the wisdom of such a 
> choice (or lack thereof) is an issue for code review and the marketplace.
> 
> Let's say that I use a little shell sort in a program; should the 
> compiler decide to replace my explicit choice of algorithm with 
> quicksort, even though I have determined that shell sort is better?
> 
> When I say "inline", I mean inline, regardless of other opinions 
> (including those of the compiler).

Really? And when you say "register" do you really mean that?  If so, then 
I'm sorry, but you are in for a big disappointment when using gcc -- it 
completely ignores the register keyword when optimizing and has done since 
~forever.

> 
> > I disagree.  What really counts is that the compiler has sufficient 
> > information to do a good job when compiling the code (ie to reduce, and 
> > hopefully eliminate, the abstraction penalty).  What constitutes a "good 
> > job" is up to the compiler...
> 
> No.
> 
> What constitutes a "good job" is defined by a human mind, not a piece of 
> technology that lacks any concept of "good." Over the years, I've found 
> many arrogant tools (and not just from Microsoft) -- tools that assume, 
> *incorrectly*, that their "wisdom" exceeds mine.
> 

I've already given examples of when the compiler can make use of context 
to give better inlining than can be determined statically.  Your 
"arrogant" assertion that inline must always and unconditionally mean 
inline impliess that programmers can never take advantage of those cases.

R.