哈希映射，字符串比较和std :: map？

Question

首先，我想提出一些我认为是真实的观点。请问这些可以验证吗？

• 哈希映射存储字符串 将它们转换为整数 不知何故。
• std :: map不是哈希映射，如果我使用字符串，我应该考虑使用哈希映射来解决内存问题吗？
• 字符串比较不好依赖。

如果std :: map不是哈希映射，我不应该依赖字符串比较（基本上，我有一个字符串作为键的地图......我被告知要使用哈希映射查找？），是在C ++ STL中有一个哈希映射？如果没有，Boost怎么样？

其次，哈希地图是否值得[原创] std::map< std::string, non-POD GameState >？

我认为我的观点正在蔓延......我计划拥有一系列不同的游戏状态，我可以查看并注册到工厂。 如果需要更多信息，请询问。

感谢您的时间。

Answer 1

我不相信你的大多数观点是正确的。

• 当前标准中没有哈希映射。 C ++ 0x引入了unordered_map，谁的实现将是一个哈希表，你的编译器可能已经支持它了。

• std :: map实现为平衡树，而不是哈希表。将地图类型与字符串一起使用时，没有“内存问题”，无论是作为键还是数据。

在任何一种情况下，

• 字符串都不会存储为数字 - unordered_map将使用散列函数从字符串中导出数字键，但不会存储。

• 我的经验是，unordered_map的速度大约是地图的两倍 - 它们基本上具有相同的界面，因此您可以尝试使用自己的数据 - 只要您对性能感兴趣，就应该始终执行自己的测试你自己的真实数据，而不是依赖他人的经验。两种地图类型都会对字符串键的长度有些敏感。

假设你有一些A类，你想通过字符串键访问，那么这些地图将被声明为：

map <string, A> amap;
unordered_map <string, A> umap;

Answer 2

我制作了一个基准，用于比较std :: map和boost :: unordered_map。 我的结论基本上是这样的：如果你不需要像equal_range这样的特定于地图的东西，那么总是使用boost :: unordered_map。 可以找到完整的基准here

Answer 3

哈希映射通常会有一些字符串的整数表示，是的。

std :: map需要进行排序，因此将其作为哈希表实现是不太可能的，而且我在实践中从未见过它。

字符串比较是好还是坏取决于你正在做什么，你要比较什么数据，以及多久。如果第一个字母不同，则与整数比较几乎没有任何不同，例如。

你想要unordered_map（这是Boost版本 - 如果你的编译器有这个版本，TR1标准库中也有一个版本。）

游戏州是否值得？是的，但仅仅因为使用unordered_map很简单。在这个阶段，你过早地担心优化问题。节省您对每秒数千次查找事物的访问模式的担忧（即，当您的分析器告诉您这是一个问题时）。