Hi Chris, My reply is below. Best regards. On Fri, 19 Aug 2005 03:08 am, random@xxxxxxxxxxxxxxx wrote: > Paul C. Leopardi wrote: > >Hi Chris, > >Thanks for your reply. My responses are below. > >Best, Paul > > > >On Thu, 18 Aug 2005 08:56 pm, random@xxxxxxxxxxxxxxx wrote: > >>Paul C. Leopardi wrote: > >>>1. Is the difference in interface between __gnu_cxx::hash_map and > >>>std::tr1::unordered_map documented anywhere? Does the fact that I can't > >>>find any such gcc - specific documentation mean that > >>>std::tr1::unordered_map is a trivial drop-in replacement for > >>>__gnu_cxx::hash_map ? > >> ... > >>If you get a copy of the complete g++ source code, then look in > >>libstdc++-v3/testsuite/tr1/6_containers/ you'll find the testsuite for > >>the unordered containers, which should at least show the basics of how > >>they work, although I'll admit not documented. > > > >Thanks. I took a look at the documentation for TR1 and the source code. > > The tests don't look like they test std::tr1::unordered_map< K, T >, > > where K is a user defined class. All the tests look like they use > > std::string for K. So maybe std::tr1::unordered_map< K, T > is not > > supposed to work? > > > >AFAICT, since I have a user defined key class K, I need to define my own > >hash< K > class. I did this and now have a strange compilation error > > message. > > Hmm.. looks like they are actually seriously badly tested.. > > For example, just > > std::tr1::unordered_set<int> i,j; > i=j; > fails to compile! > > I'll submit that as a bug, and it should get fixed. Looks like they are > somewhat less tested than I thought :) Chris, Thanks for the bug report. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23465 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 Peter Dimov said in this proposal: "Currently, the unordered associative containers provide specializations for the hash<> class template for a selected list of built-in types and std::basic_string. However, no support is provided for writing quality hash functions for even the simplest user-defined types such as the equivalent of std::pair<int, int>. Furthermore, the specialization interface through which users may supply a default hash function for a given type is less convenient than the alternative approach of providing a function overload reachable via ADL." The proposal was closed: "Rationale: The LWG agreed that there are usability problems with the current interface, but thought that this proposal was too large, and raised too many design issues, for it to be accepted for the TR. A library of hashing primitives might be a good candidate for TR2." 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. I'm now wondering why, if the unordered associative containers are in such an embryonic state, bugs in __gnu_cxx::hash_map will remain WONTFIX. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23244 Maybe it really is better to get unordered_map working properly rather than fix hash_map. As far as I understand, since unordered_map never did work properly, any bug in unordered_map is not a regression, and therefore the bug will not be fixed in the 4.0.X branch, but only in mainline (4.1). Is this correct?
