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
