On 09/19/2012 01:12 AM, Paolo Carlini wrote:
Hi again,
On 09/18/2012 08:33 PM, Paolo Carlini wrote:
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.
I found the time to go (again, hopefully it's the last time ;) through
tr1/cmath, and now I understand why we have an issue with pow only,
not with the other functions. Ok.
On the other hand - because of that comment which you mentioned
earlier - I don't think we can just have using std::pow in namespace
std::tr1. I'm coming to the conclusion that having instead an using
::pow, instead of the open coded pow (double, double) could work. Did
you try that together with your front-end patch?
But I'm afraid this is still not completely correct, because if the user
code has a using std::pow in the global namespace and then and include
<tr1/cmath> the latter drags again in namespace std::tr1 the overloads
pow (*, int) which we don't want there... grrrrr
Paolo.
