I think that part of the issue is that the way the STL should be treated is a bit of a polarizing issue. Of course, there are technical considerations, such as some STL implementations being lacking on older platforms, but mostly Qt and the STL have some overlaps, and people can't agree on how to handle said overlaps.
I personally consider that the STL is as much part of C++ than the core language and any api should therefore be as much compatible with it as possible. Redundant algorithms & utilities ( mutex, shared pointer, etc ), should probably not exist at all at this point, though they used to make sense. As such, Qt containers should work properly with any STL types, and Qt types should work well with the STL constructs, containers, types and algorithms. Most people use Qt as a framework and play by Qt's rules, but for others Qt may just be the UI layer, an other library in the stack. Both use cases should be catered to. More on point: * You don't actually need to include anything from the STL to implement std::hash. * For qHash, maybe one or more qt_stl.h headers that would include the required stl headers. Forward declare when possible ( probably not often, sadly ). Compilations times may, for the time being, be an issue but I don't think Qt can or should work around them. I would also prefer a solution that is independent of the order of the includes. Since the flurry of last years' microoptimizations in the QString and > algorithm area had measurably negative impact on me (like time I had to > spend to work around SC breakages), but no measurable positive impact > (should I have witnessed any performance gains?) I reserve the right to > be sceptical here, unless something resembling a proof of the opposite > shows up. > Micro-optimizations on such low level classes are always worth it. > Andre' > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
