This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] for c++/54537
Hi,
"Fabien ChÃne" <fabien.chene@gmail.com> ha scritto:
>2012/9/18 Paolo Carlini <paolo.carlini@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