首先，我想提出一些我认为是正确的观点。请问这些可以验证吗？哈希映射，字符串比较和std :: map？
如果std :: map不是一个哈希映射，我不应该依赖字符串比较（基本上，我有一个映射字符串作为键...我被告知使用哈希映射来查找？ ），C++ STL中是否有哈希映射？如果不是，Boost怎么样？第二，哈希图是否值得[原] std::map< std::string, non-POD GameState >？
我认为我的观点是越过......我打算有一个不同的游戏状态存储，我可以查找并注册到工厂。 如果需要更多信息，请询问。
谢谢你的时间。
我不相信你的观点是正确的。
在当前标准中没有哈希映射。 C++ 0x引入了unordered_map，谁的实现将是一个哈希表，你的编译器可能已经支持它了。
std :: map实现为平衡树，而不是散列表。当使用带有字符串的映射类型时，不存在“内存问题”，无论是作为键还是数据。
在任何一种情况下字符串都不以数字形式存储 - unordered_map将使用散列函数从字符串中派生数字键，但不会存储该字符串。
我的经验是，unordered_map大概是地图速度的两倍 - 它们基本上具有相同的界面，所以你可以用你自己的数据尝试两种方式 - 每当你对性能感兴趣时，你应该总是用你的自我测试拥有真实的数据，而不是依赖于他人的经验。这两种地图类型都会对字符串键的长度稍微敏感。
假设你有一些类A，你想通过一个字符串键来访问，地图将被宣布为：
map <string, A> amap;
unordered_map <string, A> umap;
哈希映射通常有一个字符串的一些积分表示，是的。
std :: map有要求排序的条件，因此不可能将它作为散列表实现，而且我从来没有在实践中看到它。
字符串比较的好坏取决于你在做什么，你正在比较哪些数据以及多久。例如，如果第一个字母不同，那么它与整数比较几乎没有任何区别。
你想unordered_map（这就是Boost版本 - 如果你的编译器有这个版本，那么在TR1标准库中也有一个版本）。
它是否值得游戏邦？是的，但仅仅是因为使用unordered_map很简单。在这个阶段你过早地担心优化。对于每秒要查看数千次的内容（即，当您的分析器告诉您这是一个问题时），请避免对访问模式的担忧。
我做了一个比较std :: map和boost :: unordered_map的基准测试。 我的结论基本上是这样的：如果你不需要像equal_range这样的地图专用的东西，那么总是使用boost :: unordered_map。 可以找到完整的基准测试here
在STL扩展stdext :: hash_map中有一个哈希映射。 – Plow 2010-08-29 15:58:14