Re: std::pow implementation

[Richard Earnshaw <rearnsha at arm dot com>]

> Alexandre Oliva <aoliva@redhat.com> writes:
> 
> | On Jul 30, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> | 
> | > If you give inline its original meaning, you won't run into the risk
> | > of the situation you're describing.
> | 
> | Which meaning are you talking about? 
> 
> The meaning of "inline" when it was originally introduced in C++.  I'm
> quoting here "The Design and Evolution of C++" (also part of an
> article I intented to send to a broader audience), section "Run-Time
> Efficiency":   
> 
>   The general reason for the introduction of inline functions was
>   concern that the cost of crossing a protection barrier would cause
>   people to refrain  from using classes to hide representation.  In
>   particular [Stroustrup, 1982b] observes that people had made data
>   members public to avoid the function call overhead incurred by a
>   constructor for simple classes where only one or two assignments are
>   needed for initialization.  The immediate cause for the inclusion of
>   inline functions into C with Classes was a project that couldn't
>   afford function call overhead for some classes involved in real-time
>   processing.  For classes to be useful in that application, crossing
>   the protection barrier had to be free.
> 

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.

>   [...]
> 
>   2.4.1 Inlining
> 
>   Inlining was considered important for the utility of classes.
>   Therefore, the issue was more /how/ to provide it than /whether/ to
>   provide it.  Two arguments won the day for the notion of having the
>   programmer select which functions the compiler should try to inline.

Note the word "try" in the line above.

>   First, I had poor experiences with languages that left the job of
>   inlining to compilers "because clearly the compiler knows best."
>   The compiler only knows best if it has been programmed to inline and
>   it has a notion of time/space optimization that agrees with mine.  My
>   experience with other languages was that only "the next release"
>   would actually inline, and it would do so according to an internal
>   logic that a programmer couldn't effectively control. [...]
>   Furthermore, techniques that require global analysis, such as
>   automatic inlining without user support, tend not to scale well to
>   very large programs.  C with Classes was designed to deliver
>   efficient code given a simple, portable implementation on
>   traditional systems.  Given that, the programmer had to help.  Even
>   today, the choice seems right.
> 
> 
> Reference [Stroustrup, 1982b] is
>  Bjarne Stroustrup: "Adding Classes to C: An Exercise in Language
>                      Evolution".  Bell Laboratories Compuer Science
>                      internal document.  April 1982.  
>                      Software: Practice & Experience, Vol 13. 1983
>   
> 
> Never forget that inlining is a *key* feature for the effective use
> and utsefulness of classes. 

Not disputed.

> "Inline" was introduced to give control
> to the programmer.

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 and we can spend as much time as we want 
disputing whether the compiler has reached that standard; however, to 
reach it does not necessarily have to mean that it conceptually 
substitutes every statement from the body of an "inline" function into the 
caller.

Careful use of inline by the programmer will aid the compiler in achieving 
that goal.

R.