最坏情况平衡树稳一些
【 在 allegro 的大作中提到: 】
: 时间复杂度unordered_map吊打。
: 空间复杂度差不多，stl实现里面unordered_map的一个node的额外消耗只有map的node的一半。
: 如果不需要一颗排好序的树，基本没有什么理由使用map了吧？
: ...................
--
FROM 220.249.162.*

不见得，比如linux kernel就用了很多rbtree。
特别是你的数据如果是用户可以操纵的，用hash有被DoS攻击的可能。

【 在 here080 的大作中提到: 】
: 正常不应该这么想吧。如果你的数据居然能全hash到一块，这里面可能有别的问题了。
--
FROM 101.84.17.*

【 在 allegro 的大作中提到: 】
: 时间复杂度unordered_map吊打。
: 空间复杂度差不多，stl实现里面unordered_map的一个node的额外消耗只有map的node的一半。
: 如果不需要一颗排好序的树，基本没有什么理由使用map了吧？
需求。
如果是有序的需求，比如>key,<key，b<key<e的所有数据，等等，不等式查询，
nordered_map就没戏了。

另外，动态数据，随时插删，nordered_map就不很方便。
经常会发现，数据量小时，hash方法还不错，数据量一大，原来的hash方法不适合了，这时比较难处理。

除去上述情况，就可以选择nordered_map。
--
修改:ylh1969 FROM 221.221.50.*
FROM 221.221.50.*

有一些安全issue从这里来的，所以有些应用会考虑。我就记得java有利用hash函数缺陷做dos攻击的，这个出问题以后很难避开
【 在 here080 的大作中提到: 】
: 正常不应该这么想吧。如果你的数据居然能全hash到一块，这里面可能有别的问题了。
: 【 在 milksea (肥了，又肥了 >>>_<<<) 的大作中提到: 】
: : 标  题: Re: 主题:比起std::unordered_map，还有使用std::map的必要吗？
: ...................
--
FROM 220.249.162.*

查了一下，java 这个是 CVE-2012-2739。

hash造成的性能问题（造成DoS就算安全问题）很底层，影响面就广。当然你说的不错绝大多数应用是不会出问题的，但面对刻意构造恶意数据包的攻击者来说，找到一个利用点就足够了，所以面对安全缺陷讨论条件常见与否就不太重要了。

事实上不止jvm出过这种安全问题，php、ruby等等好多语言或者框架也都有过类似的 CVE 漏洞。与其说是具体实现中hash函数取得不够好（一般是字符串的hash出问题），不如说hash表数据结构本身在性能退化方面风险就更大。

c++11 以前没有一开始定义 hashmap 是历史原因，但先定义有序的 map（下面可以是平衡树、b树或跳表之类），也确实有 hash 函数不好定义以及性能退化方面的考虑。印象里 Stroustrup 在哪儿提过，或者是 tc++pl，或者是《设计与演化》。

说到实现上的困难，即使今天，没有静态反射的 C++ 给自定义键类型添加 hash 重载还是挺繁琐易错的。而有反射的语言通常只要求有 operator== 就行。
【 在 here080 的大作中提到: 】
: hash攻击一般是针对数据库的吧。
: 放到容器里只能说这个系统太小作坊了。
: 【 在 milksea (肥了，又肥了 >>>_<<<) 的大作中提到: 】
: ...................
--
FROM 120.36.50.*