Daniel James wrote:
John Maddock wrote:
I'm not sure that would work unfortunately: if I have one library that uses the TR1 <functional> and another that uses <boost/functional/hash.hpp> and then include both libraries in my code, will they both work? Which "version" of the hash lib do I get?
The extensions would only be disabled if the user defines the macro, I don't think they should be disabled by default. If you're worried about ODR conflicts they can easily be avoided. The only cost is that the class is now specialized for the types mentioned in TR1, instead of just having a single definition.
I guess there is a problem with something like: a.hpp: #define BOOST_HASH_NO_EXTENSIONS #include <functional> // .... b.hpp: #include <functional> // .... a.cpp: #include "a.hpp" #include "b.hpp" But this would really be against the intent of the macro - which is to check that your code is not inadvertantly making use of the extensions. I will suggest in the documentation that the macro is only used as a compiler switch, and never in headers. Or, I could just have two classes boost::hash & boost::tr1::hash (or whatever). All of the implementation will still be in hash_value etc. so there wouldn't be any code bloat. The macro would only affect boost::tr1::hash, which would still include the extensions by default. But that seems overly complicated. Just so you understand what I'm getting at, here's some (untested and probably incorrect) code. namespace boost { template <class T> struct hash; template <> struct hash<int> : public std::unary_function<int, std::size_t> { std::size operator()(int v) const { return boost::hash_value(v); } }; // etc. #if !defined(BOOST_HASH_NO_EXTENSIONS) template <class T> struct hash<T> : public std::unary_function<T, std::size_t> { std::size operator()(T v) const { return hash_value(v); } }; #endif } Can you see any other problems with it? Daniel