Hashing string16s.

I'm apparently the first one who's tried to do hash_map<string16, ...>.  Unfortunately, hash_map<> does not know how to hash a string16 when string16 isn't a wstring.  I looked in <tr1/functional> and saw that only std::string and std::wstring have hashing functions.

This change adds a hashing function for string16's when they're not the same as a std::wstring.

BUG=none
TEST=none



Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=21494

[jorlow, 2009-07-23 23:20:10]

Added the guard Darin suggested.

Please take a look?

[Mark Mentovai, 2009-07-23 23:27:40]

LG otherwise

http://codereview.chromium.org/160062/diff/1/2
File base/hash_tables.h (right):

http://codereview.chromium.org/160062/diff/1/2#newcode19
Line 19: #include "build/build_config.h"
When this file is #included, it must come before our other #includes (but after
any system #includes).

http://codereview.chromium.org/160062/diff/1/2#newcode97
Line 97: template<>
You should wrap this new section inside #ifdef WCHAR_T_IS_UTF32.

http://codereview.chromium.org/160062/diff/1/2#newcode98
Line 98: struct hash<string16> {
Add a comment stating that this code comes from GNU libstdc++ but we've changed
the types to work with string16.

http://codereview.chromium.org/160062/diff/1/2#newcode117
Line 117: template<>
And I'd also put the two new template structs below this one, because this one
conceptually goes with the ones that precede it in that it's just a call through
to std::tr1::hash.

http://codereview.chromium.org/160062/diff/1/2#newcode120
Line 120: return std::tr1::hash<long>()((long) i);
Also, not your code, but this cast is complete and total BS.

[jorlow, 2009-07-23 23:41:59]

New version uploaded.

http://codereview.chromium.org/160062/diff/1/2
File base/hash_tables.h (right):

http://codereview.chromium.org/160062/diff/1/2#newcode19
Line 19: #include "build/build_config.h"
On 2009/07/23 23:27:40, Mark Mentovai wrote:
> When this file is #included, it must come before our other #includes (but
after
> any system #includes).

Done.

Also added in the "base/" which I forgot.

http://codereview.chromium.org/160062/diff/1/2#newcode97
Line 97: template<>
On 2009/07/23 23:27:40, Mark Mentovai wrote:
> You should wrap this new section inside #ifdef WCHAR_T_IS_UTF32.

Done.

http://codereview.chromium.org/160062/diff/1/2#newcode98
Line 98: struct hash<string16> {
On 2009/07/23 23:27:40, Mark Mentovai wrote:
> Add a comment stating that this code comes from GNU libstdc++ but we've
changed
> the types to work with string16.

Done.

http://codereview.chromium.org/160062/diff/1/2#newcode117
Line 117: template<>
On 2009/07/23 23:27:40, Mark Mentovai wrote:
> And I'd also put the two new template structs below this one, because this one
> conceptually goes with the ones that precede it in that it's just a call
through
> to std::tr1::hash.

Done.

http://codereview.chromium.org/160062/diff/1/2#newcode120
Line 120: return std::tr1::hash<long>()((long) i);
On 2009/07/23 23:27:40, Mark Mentovai wrote:
> Also, not your code, but this cast is complete and total BS.
worrisome
Do you want me to do anything about it?  It does seem worrisome though...  Maybe
I should file a bug?

[Mark Mentovai, 2009-07-24 00:01:33]

LGTM

http://codereview.chromium.org/160062/diff/1006/1007
File base/hash_tables.h (right):

http://codereview.chromium.org/160062/diff/1006/1007#newcode101
Line 101: return std::tr1::hash<long>()((long) i);
You don't have to fix this in this CL.  You can do a follow-up, or if you don't
want it (or don't want to do it now), at the very least, definitely file a bug.

http://codereview.chromium.org/160062/diff/1006/1007#newcode110
Line 110: // make it compile.  The lib only defines the hash for string and
wstrings.
"strings and wstrings" or (my preference) "string and wstring"

http://codereview.chromium.org/160062/diff/1006/1007#newcode122
Line 122: // make it compile.  The lib only defines the hash for string and
wstrings.
Ditto.

[jorlow, 2009-07-24 00:12:29]

Submitting.

http://codereview.chromium.org/160062/diff/1006/1007
File base/hash_tables.h (right):

http://codereview.chromium.org/160062/diff/1006/1007#newcode101
Line 101: return std::tr1::hash<long>()((long) i);
On 2009/07/24 00:01:33, Mark Mentovai wrote:
> You don't have to fix this in this CL.  You can do a follow-up, or if you
don't
> want it (or don't want to do it now), at the very least, definitely file a
bug.

What's the correct fix though?  I'm 99% sure std::tr1::hash<long long> is
undefined which is why they did this.

To be honest, I'm not sure this is terribly insane.  I think most long longs are
that way only to handle corner cases and thus it's not insane to assume the
higher order bits don't matter.

Anyway, I guess we can follow up in http://crbug.com/17606

http://codereview.chromium.org/160062/diff/1006/1007#newcode110
Line 110: // make it compile.  The lib only defines the hash for string and
wstrings.
On 2009/07/24 00:01:33, Mark Mentovai wrote:
> "strings and wstrings" or (my preference) "string and wstring"

Done.

http://codereview.chromium.org/160062/diff/1006/1007#newcode122
Line 122: // make it compile.  The lib only defines the hash for string and
wstrings.
On 2009/07/24 00:01:33, Mark Mentovai wrote:
> Ditto.

Done.