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

["Paul C. Leopardi" <leopardi at bigpond dot net dot au>]

Hi Chris,
My reply is below.
Best regards.
On Fri, 19 Aug 2005 03:08 am, random@bubblescope.net 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@bubblescope.net 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?