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

[Marc Glisse <marc dot glisse at inria dot fr>]

On Thu, 18 Aug 2011, Paolo Carlini wrote:

> Indeed. I would say let's not re-order for now, I'll have a further look 
> later on.

Is that a "ok" for Rainer or just part of the discussion?

> > >     * include/tr1/cmath (float fabs(float), long double fabs(long
> > >     double)): Wrap in !__CORRECT_ISO_CPP_MATH_H_PROTO1.
> >
> > There is a comment:
> >   // Note: we deal with fabs in a special way, because an using std::fabs
> >   // would bring in also the overloads for complex types, which in C++0x
> >   // mode have a different return type.
> >
> > and then it proceeds to using ::fabs and declare the float and long double 
> > overloads. Now on solaris, using ::fabs is going to be equivalent to using 
> > std::fabs. I don't know if that creates problems for the complex types, and 
> > in that case what can be done about it (declare fabs(double) instead of 
> > importing the global one?).
> We have a testcase for that issue, see Rev 170083, 
> testsuite/tr1/headers/c++200x/complex.cc.

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...

--
Marc Glisse