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
