Re: std::pow implementation

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

Richard Earnshaw <rearnsha@arm.com> writes:

| > 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").

Do you think 'std::string::end() const' is not very small?
I certainly think it is.

| 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).

Firstly, I do not trust you that counting lines is sensical mesure for
inlining.  Secondly, it is up to the programmer to decide whether he
wants the 2000 lines in the middle his class.  Whether it is stupid
depends on what he is doing and *you* have no cluie to know that.

Do trust the programmer.

|  A practical compiler 
| eventually has to say "enough is enough", or it is likely to crash, run 
| out of memory or whatever.

That compiler is broken then.  More specifically you don't have any
clue in foreseeing that.  Or else you end reinventing "inline" with a
different syntax, namely __attribute__((__always_inline__)) or
-fobey-inline.  With no pruposes (apart from offerind a lock-in syntax).

| >   [...]
| > 
| >   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.

Yes, I noted it.  But "try" don't not imply "give up because you think
you know better than the programmer".

| >   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.

But that is the root of the disagreement!

[...]

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

But when the compiler thinks he knows better than the programmer and
implementors insist on transmuting the original meaning of the
keyword, the compiler won't achieve its goal.

-- Gaby