Is std::tr1::unordered_map supposed to be working yet?

[Paul C. Leopardi]

Hi Chris,
I answer some of my own questions below.
Best, Paul
On Fri, 19 Aug 2005 10:15 am, Paul C. Leopardi wrote:
> It seems that TR1 itself has usability problems with its support for user
> defined hash functions for std::tr1::unordered_map< K, T > where K is a
> user defined class. See "Library Extension Technical Report Issues List,
> Revision 10: June 2005 mid-meeting mailing" N1837, item 6.18 pp. 63--67.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1837.pdf
...
> So, it looks to me like there is supposed to be a way for me to write a
> user defined hash function, but it is not well enough documented for me to
> tell the difference between my own errors and errors in the compiler or the
> library.

The boost::hash library is an implementation of both TR1 and item 6.18, 
allowing user defined hash functions.

http://boost.org/doc/html/hash.html

The boost::hash library documentation also includes exactly the usage example 
I need to be able to define my own hash functions.

http://boost.org/doc/html/hash/custom.html

Unfortunately, even when using boost::hash, I still see error messages when 
compiling. My code now looks like:

#include <boost/functional/hash.hpp>
#include <tr1/unordered_map>
...
template< const glucat::index_t LO, const glucat::index_t HI > 
inline size_t hash_value(index_set<LO,HI> val)
{
 return val.hash_fn();
};
...
template< typename Scalar_T, 
const index_t LO = DEFAULT_LO, const index_t HI = DEFAULT_HI > 
class framed_multi : 
public 
clifford_algebra< Scalar_T, index_set<LO,HI>, framed_multi<Scalar_T,LO,HI> >, 
private
std::tr1::unordered_map< index_set<LO,HI>, Scalar_T, 
boost::hash< index_set<LO,HI> > > 
{
...
 int main() {
...
 typedef framed_multi<double> number;
 typedef number::index_set_t e;
 number OP = number(e(1),4.0) + number(e(2),3.0);
 }

and the error message is now

usr/local/gcc/gcc-4.0-20050728/lib/gcc/x86_64-suse-linux/4.0.2/../../../../include/c++/4.0.2/tr1/hashtable: 
In copy constructor ‘std::tr1::hashtable<Key, Value, Allocator, ExtractKey, 
Equal, H1, H2, H, RehashPolicy, cache_hash_code, mutable_iterators, 
unique_keys>::hashtable(const std::tr1::hashtable<Key, Value, Allocator, 
ExtractKey, Equal, H1, H2, H, RehashPolicy, cache_hash_code, 
mutable_iterators, unique_keys>&) [with Key = 
glucat::index_set<-0x00000000000000020, 32>, Value = std::pair<const 
glucat::index_set<-0x00000000000000020, 32>, double>, Allocator = 
std::allocator<std::pair<const glucat::index_set<-0x00000000000000020, 32>, 
double> >, ExtractKey = Internal::extract1st<std::pair<const 
glucat::index_set<-0x00000000000000020, 32>, double> >, Equal = 
std::equal_to<glucat::index_set<-0x00000000000000020, 32> >, H1 = 
boost::hash<glucat::index_set<-0x00000000000000020, 32> >, H2 = 
Internal::mod_range_hashing, H = Internal::default_ranged_hash, RehashPolicy 
= Internal::prime_rehash_policy, bool cache_hash_code = false, bool 
mutable_iterators = true, bool unique_keys = true]’:
/usr/local/gcc/gcc-4.0-20050728/lib/gcc/x86_64-suse-linux/4.0.2/../../../../include/c++/4.0.2/tr1/unordered_map:59:   
instantiated from here
/usr/local/gcc/gcc-4.0-20050728/lib/gcc/x86_64-suse-linux/4.0.2/../../../../include/c++/4.0.2/tr1/hashtable:1046: 
error: no matching function for call to 
‘std::tr1::hashtable<glucat::index_set<-0x00000000000000020, 32>, 
std::pair<const glucat::index_set<-0x00000000000000020, 32>, double>, 
std::allocator<std::pair<const glucat::index_set<-0x00000000000000020, 32>, 
double> >, Internal::extract1st<std::pair<const 
glucat::index_set<-0x00000000000000020, 32>, double> >, 
std::equal_to<glucat::index_set<-0x00000000000000020, 32> >, 
boost::hash<glucat::index_set<-0x00000000000000020, 32> >, 
Internal::mod_range_hashing, Internal::default_ranged_hash, 
Internal::prime_rehash_policy, false, true, 
true>::m_allocate_node(Internal::hash_node<std::pair<const 
glucat::index_set<-0x00000000000000020, 32>, double>, false>*&)’
compilation terminated due to -Wfatal-errors.

At this point, it looks like a bug in libstdc++ and not a usage error on my 
part.