[C++ Patch] for c++/54537

Paolo Carlini paolo.carlini@oracle.com
Tue Sep 18 23:40:00 GMT 2012


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.



More information about the Libstdc++ mailing list