Re: Help migrating hash_set to c++0x
On Dec 21, 9:05 pm, Howard Hinnant <howard.hinn...@gmail.com> wrote:
On Dec 21, 2:54 pm, James Kanze <james.ka...@gmail.com> wrote:
On Dec 21, 4:05 pm, Howard Hinnant <howard.hinn...@gmail.com> wrote:
[...]
In C++0x std::hash<char const*> simply hashes the pointer,
not a null terminated string.
Why did they do that? I can see hashing the pointer for other
pointer types, but char const*? (Of course, if the indices are
strings, which is usually the case, hash<std::string> seems more
logical.)
Because it makes the behavior uniform for different pointer types.
Like in iostream. For better or for worse, it's a different
behavior that most programmers are used to, and even count on.
This is a big win in generic code. For example storing pointers or
iterators in containers is common practice.
You mean an excessively dangerous practice, banned by a lot of
coding guidelines. (Iterators and pointers tend to become
invalid at inconvenient times.)
Making hash<char*> behave differently than hash<int*> would
have even more severe consequences than making vector<bool>
behave differently than vector<int>.
Come now. In both cases, all that's needed is a little
specialization (or overloading, if it's a question of
functions). With the difference that I suspect unordered
containers are fairly rare in generic code, where as vectors
aren't.
If there is a silver lining to the vector<bool> cloud, it is
that it taught us a lesson in generic programming. Best we
not forget that lesson.
The problem with vector<bool> isn't just that it's unorthogonal.
It's that it doesn't meet any of the requirements for a
container. (Arguable, some of the requirements may be
overspecification; it's a bit hard that operator[] must return a
real reference, for example. But that's a different issue.)
If we were designing the language from zero, I'd totally agree
with you. But we're not, and for better or worse, char const*
is, in most people's minds (and in a lot of the interfaces we
have to deal with), a string.
Anyway, I doubt that it's a real problem. Since the standard
doesn't make any quality guarantees (and I don't see how it
could), no one will actually use the standard hash function
anyway. (It suffers from the same problem rand() does: anything
that's good enough to work in all cases will be unnecessarily
slow in a number of frequent cases.)
--
James Kanze