Hi,
"Fabien Chêne" <fabien.ch...@gmail.com> ha scritto:
>2012/9/18 Paolo Carlini <paolo.carl...@oracle.com>:
>
>> I don't understand: what's wrong - exactly - with the std::tr1::pow
>(double, double) overload above? Now I can't immediately check, but do
>the EDG and CLANG front ends accept it or not?
>
>They don't. The problem is that it conflicts with ::pow(double,double).
>
>// in GLIBC math.h
>extern double pow (double __x, double __y) throw (); // (1)
>
>// in std::tr1::cmath
>namespace std { namespace tr1 {
>inline double
>pow(double __x, double __y)
>{ return std::pow(__x, __y); }
>}}
>
>// in std::tr1::math.h
>using std::tr1::pow; // this one conflicts with (1)
Thus, *this* is the problem. You have to add to your previous snippet an using
in the global namespace to see it.
But I'm not surprised, frankly, I think the conflict is expected, *IF* (please
check) TR1 says that those three overloads, for float, double an long double,
must be declared in std::tr1 (likewise for all the other math functions) Now,
given that our implementation has the C math.h injecting stuff in the global
namespace - and that is legal - I would say that there is nothing to fix, maybe
just a library testcase to tweak. As a matter of QoI the idea of having in tr1
using std::pow seems good, if this is what you are suggesting. At this stage
however tr1 is really in *deep* regressions only mode, and this is a pretty
large change isnt'it? This impacts all the math functions not just pow, right?
Paolo
