From: Andrew Ross <andrewross@us...> - 2004-10-06 19:00:36
On Wed, Oct 06, 2004 at 10:55:31AM -0700, Alan Irwin wrote:
> Hi Andrew,
> While starting to investigate Bryan's single-precision fortran concerns, I
> did a general single-precision check (using the --without-double ./configure
> option) and ran into a number of problems involving the pow function with
> the C++ examples. Typical compile errors were the following:
> Making all in c++
> make: Entering directory /tmp/examples_single/c++'
> g++ x01cc.cc -o x01cc `plplot-config --cflags --libs --with-c++`
> g++ x01.cc -o x01 `plplot-config --cflags --libs --with-c++`
> x01.cc: In member function void x01::plot1(int)':
> x01.cc:244: error: ISO C++ says that double pow(double, double)' and float
> std::pow(float, float)' are ambiguous even though the worst conversion
> the former is better than the worst conversion for the latter
> x01.cc:244: error: ISO C++ says that double pow(double, double)' and
> std::pow(float, int)' are ambiguous even though the worst conversion for
> former is better than the worst conversion for the latter
> make: *** [x01] Error 1
> If I tried make -k, there were a number of routines where the pow problem
> occurred. I assume one way to fix this is to go through and do specific
> casts appropriate for the pow function, but do you know a better solution?
> BTW, when you attempt to verify this I suggest you proceed from an
> absolutely clean start from current CVS HEAD and use a unique install
> prefix. Otherwise the double-precision plplot libraries lying around may
> obfuscate the error.
Urgh. This is the usual mess of standards. pow (which takes double
arguments) is POSIX compliant (and most other normal standards). The int
version seems to be a C++ specficic thing which works because C++ is
stricter about typing. At least on Linux there is a powf function which
should formally be used for float rather than double arguments.
According to the man page this is a C99 requirement but not in the
SVID 3, POSIX, BSD 4.3, ISO 9899 standards. I suspect we should steer
clear of this for compatibility. Which probably leaves explicit casting
or some wrapper of our own as the best option. It's a bit ugly but it
looks like the casting is the best option. Probably we should do this
for the C as well as the C++ examples to be entirely transparent.