Re: std::pow implementation

[dewar@gnat.com (Robert Dewar)]

> I did appeal to two sources: both the ISO standard and "The Design and
> Evolution of C++".  I included the ISO standard definition because it
> gives the wording on the current C++ definition and it is the result
> long elaboration on wordings that took many resources, just to make
> sure that thee substitution meaning is conveyed.  I did also appeal
> to the D&E because it does give references to the raison d'etre of
> inline in C++.  You might choose to ignore that C++ is an "evolved"
> language and ignore its history, but that is a not mistake I would
> like GCC to make.  C++ simply is not Ada.

The standard is a stand alone document, approved by ISO as such. It's meaning
if it has any meaning must be able to be deduced from its intrinsic content
like any other language standard. You cannot apply "history" to its
interpretation. This is just as true of Ada as of C++ (Ada has a long,
over 20 year, history too you know), and it is aqlso true that an Ada
compiler writer must be fully informed by this history.

For example, when we write

   type x (A : Natural) is record
      Y : String (1 .. A);
   end record;

in Ada, there is a difficult and significant question of how this is
implemented, and whether a given implementation will accept this particular
declaration. The Ada standard has absolutely nothing to say on this issue,
since it is one of implementation and code generation rather than semantics.

The Ada standard does have a useful innovation from a pragmatic point of view
in having sections called Implementation Advice, which are allowed to say
things that not strictly meaningful from a formal semantic point of view, but
which are useful pragmatically (of course these sections are not normative).

So referring to the ISO C++ standard is simply not relevant from a formal
point of view. Indeed the question on what code to generate should be
addressed from a pragmatic point of view, and of course this viewpoint must
include what C++ programmers expect historically (note that this is different
from what Gaby or any one person might believe about such expectations!)

Gaby's absolute position that any compiler that does not always inline 
everything is incorrect (presumably his intelligent C++ programmer would
expect inifinite compile time or a blowup in the case of a recursion???)
is to me highly contentious. I assume Gaby would also describe the (to me
very reasonable) strategy of the Intel compiler as incorrect.

I really think the only useful continuation of this discussoin is to have
some actual data, based on the absolutely-on-target suggestions made 
earlier this morning. 

I for one am signing off this thread till i see some data :-)