This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 08/18/2011 01:37 PM, Marc Glisse wrote:
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?
Sure. Actually the libstdc++ proper bits always were, I consider those more or less straightforward.
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)?

Thanks,
Paolo.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]