On 09/19/2012 01:24 AM, Paolo Carlini wrote:
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
You know what? All in all, I think we can go with your original idea of
just removing the overload for (double, double): what I didn't realize
the first time I saw the idea is that we have anyway the templatized pow
which forwards to std::pow. Thus, I suppose things should work pretty
well. But please add a big comment before the commented out overload.
And let's see if over the next months somebody complaints, otherwise, I
think it will be enough for TR1, at this point.
Thanks for your patience!!!
Paolo.
