This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: hash_map<> and string...
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: hash_map<> and string...
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 21 Nov 2000 23:06:24 +0100
- Cc: libstdc++ at sources dot redhat dot com
- Organization: CMLA, ENS Cachan -- CNRS UMR 8536 (France)
- References: <Pine.SOL.3.91.1001121134205.3760B@cse.cygnus.com>
- Reply-To: libstdc++ at sources dot redhat dot com
Benjamin Kosnik <bkoz@redhat.com> writes:
| > | I suspect this will get you where you want to go. If not, you're
| > | pretty much out of luck, as only fundamental types are going in this
| > | file, apparently.
| >
| > Well, any reasonable hash table library should come with a hash
| > function for fundmantal types or nearby types (i.e. pointer types).
| > It is also understandable to require the library to come with hash
| > functions defined for any type it happens to define or use, for
| > completeness purpose.
|
| I see we disagree about what is "reasonable." I think this is OK though.
:-) There is no portable way (from a user point of view) to provide a
hash function for a pointer type, that is why I find it "reasonable"
to provide hash functions for type types. I agree for integer types
the matter is debatable, but for floating point types, I thing that is
best handled by the library.
| > It is not really hard to add support for hash<std::string> but that has
| > a low priority on my TODO list. And if we start providing support
| > for std::string, there is no reason we should stop there...
|
| Right. It's this bit that concerns me. Let's not go down this path...
So, what do we do? :-)
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com