From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-03-09 16:57:11
Daniel James wrote:
> Peter Dimov wrote:
>> Do not give much weight to such char_traits definitions, issue 6.17
>> notwithstanding. The proposed extensions treat std::string as a
>> container, not as... whatever the other aspect of std::string is
>> supposed to be. That is, the hash value of a string s is defined as
>> the hash value of the range s.begin(), s.end().
>> If you look at the container requirements table, you'll see that
>> container equality is defined in terms of operator== on the elements.
>> The (bold enough) author of a string that is not a container can
>> provide an overload of hash_value (in the namespace of the
>> corresponding traits class) with the appropriate semantics.
> Well, partly I just feel like I should go along with the current
> opinion of the standards comittee. But here I do agree with them.
Do not give much weight to the opinion of the committee, either. The
resolution of the hash<string> issue follows the path of the least
resistance. It's not that other basic_string instances should not have a
hash function, it's that defining this function exposes the problems with
std::string and unordered_*.
> 'std::equal_to<std::string>' is defined as using char_traits. And if the
> hash function doesn't match std::equal_to, then I believe it's broken.
Example of the above. The hash function isn't broken. Using this hash
function in combination with std::equal_to is broken. Unfortunately, the
unordered containers do not give us a way to replace the default equality
relation. shared_ptr and weak_ptr encounter the same problem.
> Regardless of whether using char_traits was a bad idea in the first
Nobody uses nonstandard character traits. They are fundamentally broken for
a variety of reasons. Their only purpose is to generate discussions such as
this one. ;-)
But if this will make you feel better, define the overload as taking
basic_string<Ch, char_traits<Ch>, A>. Nobody will spot the difference.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk