我正在寻找一个支持频繁添加/删除的容器。我不知道容器可能有多大，但我不想因为大量的重新分配而得到摊位。我需要在性能和一致行为之间取得良好的平衡。
最初，我考虑过std :: tr1 :: unordered_map，但由于我不知道数据集的上限，因此冲突可能会降低unordered_map的性能。这不是一个好的散列函数的问题，因为无论它有多好，如果地图的占用率超过桶数的一半，碰撞可能会成为一个问题。
现在我正在考虑使用std :: map，因为它不会遇到冲突问题，但它只有log（n）性能。
当您不知道unordered_map的目标大小时，有没有办法智能地处理冲突？处理这种情况的任何其他想法，我想这并不罕见？
由于
答案 0 :(得分：1)
这是一个运行时容器，对吗？
您是在最后添加（如在push_back中）还是在前面或中间添加？
您是在随机位置移除，还是什么？
您如何引用其中的信息？ 随机，或从前面或后面，或什么？
如果您需要随机访问，则首选基于数组或散列的内容。
如果重新分配是一个大问题，你需要更像树或列表的东西。
即便如此，如果你经常new - （和delete - ）你放入容器中的对象，那么单独这个对象很可能会消耗很长一段时间，
在这种情况下，您可能会发现将已使用的对象保存在垃圾列表中是有意义的，因此您可以回收它们。
我的建议是，而不是选择容器，只需选择一个，编写程序，然后tune it, as in this example。 无论你选择什么，你可能都想改变它，也许不止一次。 我在这个例子中发现的是，任何预先存在的容器类都可以通过编程的简单性来证明它的存在，而不是以最快的速度。
我知道这是违反直觉的，但是 除非您的程序中的某些其他活动最终成为主导成本，并且您无法缩小它，否则您的最终速度将需要手动编码数据结构。
答案 1 :(得分：0)
您需要什么样的访问权限？顺序，随机访问，按键查找？另外，您可以手动（rehash方法）重新设置无序地图，并设置其加载因子。在任何情况下，当链变得太长时（即，当超过加载因子时），散列将重建自身。另外，哈希表的减速点是满的~80％，而不是50％。
您应该阅读文档，例如here。