我遇到了这个好问题,它很相似,但完全不同,因为它讨论了 Java,它具有不同的哈希表实现,因为它具有同步访问器/mutators:Java 中的 HashMap 和 Hashtable 有什么区别?
I came across this good question, which is similar but not at all same since it talks about Java, which has different implementation of hash-tables, by virtue of having synchronized accessor /mutators: What are the differences between a HashMap and a Hashtable in Java?
那么set
和unordered_set
的C++实现有什么区别?这个问题当然可以扩展到map
vs unordered_map
等其他C++容器.
So what is the difference in C++ implementation of set
and unordered_set
?
This question can be of course extended to map
vs unordered_map
and so on for other C++ containers.
这是我的初步评估:
set
:虽然标准没有明确要求将其实现为树,但要求其查找/插入操作的时间复杂度约束意味着它将始终作为树实现.通常作为高度平衡的 RB 树(如 GCC 4.8 中所见).由于它们是高度平衡的,它们对于 find()
set
: While the standard doesn't explicitly ask it to be implemented as trees, the time-complexity constraint asked for its operations for find/insert, means it will always be implemented as a tree.
Usually as RB tree (as seen in GCC 4.8), which is height-balanced.
Since they are height balanced, they have predictable time-complexity for find()
优点:紧凑(与其他 DS 相比)
Pros: Compact (compared to other DS in comparison)
缺点:访问时间复杂度为 O(lg n)
Con: Access time complexity is O(lg n)
unordered_set
:虽然标准没有明确要求将其实现为树,但要求其查找/插入操作的时间复杂度约束意味着它将始终作为哈希实现-表.
unordered_set
: While the standard doesn't explicitly asks it to be implemented as trees, the time-complexity constraint asked for its operations for find/insert, means it will always be implemented as a hash-table.
优点:
缺点:
注意:哈希表的 O(1) 来自没有冲突的假设.即使负载因子为 0.5,每插入一秒变量都会导致冲突.可以看出,哈希表的负载因子与访问其中元素所需的操作数成反比.更多我们减少#operations,更稀疏的哈希表.当存储的元素大小与指针相当时,开销就相当可观.
Note: The O(1), for hashtable comes from the assumption that there are no collision. Even with load-factor of .5, every second variable insertion is leading to collision. It could be observed that the load-factor of hash-table is inversely proportional to the number of operations required for accessing a element in it. More we reduce #operations, sparser hash-table. When the element stored are of size comparable to pointer, then overhead is quite significant.
我是否错过了应该知道的性能分析地图/集合之间的任何区别?
我认为您通常已经回答了您自己的问题,但是,这个:
I think you've generally answered your own question, however, this:
不像树那么紧凑.(出于实际目的,负载因子永远不会是 1)
Not as compact as tree. (for practical purposes load factors is never 1)
不一定正确.T
类型的树的每个节点(我们假设它是红黑树)使用的空间至少等于 2 * pointer_size + sizeof(T) + sizeof(布尔)
.这可能是 3 * 指针大小
,具体取决于树是否包含每个树节点的 parent
指针.
is not necessarily true. Each node of a tree (we'll assume it's a red-black tree) for a type T
utilizes space that is equal to at least 2 * pointer_size + sizeof(T) + sizeof(bool)
. This may be 3 * pointer size
depending on whether the tree contains a parent
pointer for each tree node.
将其与哈希映射进行比较:由于 加载因子 <的事实,每个哈希映射都会浪费数组空间.1
正如你所说的.然而,假设哈希映射使用单向链表进行链接(实际上,没有真正的理由不这样做),插入的每个元素仅采用 sizeof(T) + 指针大小
.
Compare this to a hash-map: there will be wasted array space for each hash map due to the fact that load factor < 1
as you've said. However, assuming the hash map uses singly linked lists for chaining (and really, there's no real reason not to), each element inserted take only sizeof(T) + pointer size
.
请注意,此分析忽略了可能来自对齐使用的额外空间的任何开销.
Note that this analysis ignores any overhead which may come from extra space used by alignment.
对于任何具有小尺寸的元素T
(因此,任何基本类型),指针的大小和其他开销占主导地位.在 > 的负载系数下;0.5
(例如)std::unordered_set
可能确实比等效的 std::set
使用更少的内存.
For any element T
which has a small size (so, any basic type), the size of the pointers and other overhead dominates. At a load factor of > 0.5
(for example) the std::unordered_set
may indeed use up less memory than the equivalent std::set
.
另一个重要的缺失点是,基于给定的比较函数,遍历 std::set
保证产生从小到大的排序,同时遍历 std::set
>std::unordered_set 将以随机"顺序返回值.
The other big missing point is the fact that iterating through a std::set
is guaranteed to produce an ordering from smallest to largest, based on the given comparison function, while iterating through an std::unordered_set
will return the values in a "random" order.
这篇关于C++ 中的 set 和 unordered_set 有什么区别?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持html5模板网!