Hi Boosters,
I'm sure I'm not the first person to be caught out by this. If you try
to use Boost.Functional/Hash on a smart pointer type such as
boost::shared_ptr, the results may be, well, underwhelming:
typedef boost::shared_ptr<int> IPtr;
IPtr i1 = IPtr(new int(1234));
IPtr i2 = IPtr(new int(4321));
std::cout << std::hex
<< "hash(i1): " << boost::hash<IPtr>()(i1) << "\n"
<< "hash(i2): " << boost::hash<IPtr>()(i2) << "\n";
which produces:
hash(i1): 1
hash(i2): 1
This is because the shared_ptr is being silently converted to a boolean
type before being hashed. Now maybe this is all documented and so forth
but I would argue that it's not really expected behaviour. Or to put it
another way, it's very easy to go wrong and use smart pointers in a
hashed container such as a boost::unordered_set. The performance of
such a set obviously degrades considerably, when compared to a more
intelligent hash function. Here's a simple snippet to show the problem:
typedef boost::shared_ptr<int> IPtr;
template <typename T>
struct PtrHash
: public std::unary_function
{
std::size_t operator() (boost::shared_ptr<T> const& ptr) const
{
return boost::hash()(ptr.get());
}
};
template <typename Set>
double TimeInserts(int i)
{
Set s;
boost::timer t;
while (i--)
s.insert(IPtr(new int(i)));
return t.elapsed();
}
int main()
{
typedef boost::unordered_set<IPtr> IPtrSetDefaultHash;
typedef boost::unordered_set IPtrSetPtrHash;
const int iterations = 10000;
std::cout << std::dec
<< "IPtrSetDefaultHash: " <<
TimeInserts<IPtrSetDefaultHash>(iterations) << "s\n"
<< "IPtrSetPtrHash: " <<
TimeInserts<IPtrSetPtrHash>(iterations) << "s\n";
return 0;
}
Which outputs:
IPtrSetDefaultHash: 2.14526s
IPtrSetPtrHash: 0.006855s
... a noticable performance difference.
OK so obviously it is reasonable to want to question the wisdom of
using a smart pointer type in a hashed container like this. But I want
to ignore that question for now, and instead ask whether it is possible
to *prevent* the conversion of smart pointers to bool for the purposes
of calculating hash values.
The context for this question is a fairly large codebase with extensive
use of hashed containers. Not everyone on the development team is aware
of this particular limitation of smart pointers. So not only do I want
to detect the use of "dangerous" hashing functions but also prevent
them being used in the future. Instead I really want to either fix or
prevent the conversion to bool for smart pointers when used in a
hashing function (either through the boost:: or tr1:: namespace).
One idea is to patch the boost headers to add a hash function for each
of the smart pointer types (as per the example above) but there must be
a better answer than this?
Does this problem affect anyone else? How do people deal with this?
