Re: std::pow implementation

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.

  [...]

  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.
  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.  "Inline" was introduced to give control
to the programmer.  The experiences reported by Stroustrup were about
more than twenty years ago;  however, they sound so familiar, to
contemporary today.  Please do give "inline" its ogirinal and obvious
meaning.  We don't need to reinvent "inline" and the obvious syntax is
already available.  Transmuting the meaning of "inline" does bring
nothing except Fear, Uncertainty and Doubt.  Keep it simple.

| The meaning assigned to inline
| in C++98 or in C99?  They have very different meanings, besides the
| issue on whether inline affects the linkage of a function in C.

The issue, as you certainly have noted if you followed the discussion,
is much more C++ specific than C specific.  I'll let C people decide
whether they wanted implementors to treat "inline" as void of semantics.

| > | They are not designed to tune inlining, they're designed to impose
| > | requirements on the compiler's behavior.  If they're abused for other
| > | purposes, there's unfortunately nothing we can do about it other than
| > | try to educate people about their intended uses.
| 
| > Why do you think "inline" is different?
| 
| Because at least in C99, inline is defined as a hint to make the

The C++/C99 standard do not mandate a useful implementation.
Surely, when we're talking about compiler performance you're not going
to quote C++/C99 standard, right?

-- Gaby