This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Is std::tr1::unordered_map supposed to be working yet?
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?