Boost logo

Boost :

From: Daniel James (daniel_at_[hidden])
Date: 2005-10-10 13:54:34

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:


#include <functional>
// ....


#include <functional>
// ....


#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.

     template <class T> struct hash<T>
         : public std::unary_function<T, std::size_t>
         std::size operator()(T v) const
             return hash_value(v);

Can you see any other problems with it?


Boost list run by bdawes at, gregod at, cpdaniel at, john at