[v3] Use Solaris prototypes if possible (PR libstdc++-v3/1773)

[Marc Glisse]

On Thu, 18 Aug 2011, Paolo Carlini wrote:
> On 08/18/2011 01:37 PM, Marc Glisse wrote:
>> namespace std {
>>         void f();
>> }
>> using std::f;
>> namespace std {
>>         struct Complex{};
>>         void f(Complex){}
>> }
>> //using std::f;
>> namespace std {
>>         using ::f;
>>         namespace tr1 {
>>                 using ::f;
>>                 void f(std::Complex);
>>         }
>> }
>> 
>> The compiler doesn't complain for this. It does if I change which using is 
>> commented out [namespace.udecl]p11 in C++11. I just learned this rule and 
>> haven't thought about the consequences yet. It looks like as long as math.h 
>> is included before complex (and complex includes cmath so that's the case), 
>> the std::fabs(std::complex) overload is not imported in the global 
>> namespace and hence not in tr1 either. On the other hand, it means that the 
>> overloads in cmath for cos/sin/etc taking an integral type are not imported 
>> in the global namespace (so std::cos(0) works but cos(0) is ambiguous). 
>> Well, it seems ok for now...
> Thus, if I understand correctly your analysis (sorry I'm in the middle of 
> something else) are we already ok? Is there something simple we can/should do 
> right now to improve things (on Solaris and/or Linux)?

I think the current patch is good enough for now (cool, I am reviewing my 
own patch (improved by Rainer) ;-).

In the longer term, there is the usual idea that we could rename the 
current cmath (just taking this one as an example) to math.h, make it 
#include_next the system math.h (instead of plain #include), and have a 
trivial cmath that just includes math.h. This way all the goodness in 
cmath would already be available in math.h, conforming to D.5 (which one 
between math.h and cmath is a trivial wrapper to the other is a technical 
detail that doesn't matter if both are installed in the same directory).

-- 
Marc Glisse