Date: Fri, 12 May 1995 15:09:30 +0900
From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To: DJGPP AT SUN DOT SOE DOT CLARKSON DOT EDU
Subject: pow()

A.APPLYARD disgusts the following:

   #include<math.h>
   main(){int i,j; double x,y;
   pow(i,j);
   pow(x,i);
   pow(x,y);}

     This program compiled OK. I recompiled it with -E, to get the
   preprocessed form (i.e. after obeying the #directives), and I found
   that of gcc's various pow(,) functions, the #included matter only
   had pow(double,double).
    If I instead #include <builtin.h>, the #included matter also has
   pow(long int,long int) and pow(double,long int), so that supposedly
   pow(,) with integer exponent is obeyed by a quick method. But what
   actually happens is:-

   C:\WORK>c:\djgpp\bin\gcc t$1.cc
   t$1.cc: In function `int main()':
   t$1.cc:3: call of overloaded `pow' is ambiguous
   c:/djgpp/cplusinc/builtin.h:47: candidates are: pow(long int, long int)
   c:/djgpp/cplusinc/builtin.h:46:                 pow(double, long int)
[chomp]

     How ever can I get all three of these pow(,) functions current at
   once?, so that any call of pow(,) gets the form that needs the
   least amount of implicit coercions, like I thought was the rule and
   the purpose of overloading?

Answer #1: go ask on comp.lang.c++ and gnu.g++.help, where this post
really belongs.

Long as I'm here....

Answer #2: According to the ARM (don't have it here but was reading
the relevant section last night :), you did get the form involving "the
least amount of implicit conversions," that amount being "one standard
conversion":

(0) exact matches are preferred to all else
(1) matches involving only trivial conversions (involving adding const
    or volatile specifiers) are preferred over all matches involving
    other conversions
(2) matches involving only integral promotion are preferred to those
    not mentioned in 0 or 1
(3) matches involving only standard conversions are preferred to those
    not mentioned in 0, 1, or 2
(4) matches involving fewer conversions are preferred to longer chains
    when 0, 1, 2, or 3 do not apply.

I believe that "integral promotion" is for compatibility with C's
argument passing conventions, and that therefore int -> long int is a
standard conversion, not an integral promotion.  (If this is false,
what you are observing is a bug.)  int -> double is also a one-step
standard conversion.  Thus these are tied and the call is ambiguous.
Sorree!  You must use an explicit cast.  You could automagicate the
process with your own file my_builtin.h:

#ifndef MY_BUILTIN_H
#define MY_BUILTIN_H
#include <built_in.h>

inline long int pow (int b, long int e)
{
    return pow ((long int) b, e);
}
#endif

I don't recommend munging the standard header, of course.

-- 
Stephen Turnbull  /  Yaseppochi-gumi  /  <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
http://turnbull.sk.tsukuba.ac.jp/      anon FTP: turnbull.sk.tsukuba.ac.jp
Check out Kansai-WWW, too ------------> http://pclsp2.kuicr.kyoto-u.ac.jp/