我实际上发现标准集容器对我自己几乎没有用，并且喜欢只使用数组，但是我以不同的方式来做。
要计算集合相交，我遍历第一个数组并用单个位标记元素。然后，我遍历第二个数组并查找标记的元素。瞧，在线性时间中设置交集比散列表要少得多的工作和内存，例如，使用这种方法，联合和差同样容易应用。它确实有助于我的代码库围绕索引元素而不是复制它们（我将索引复制到元素，而不是元素本身的数据），并且几乎不需要排序任何东西，但是多年来我没有使用任何设置的数据结构结果。
即使元素没有提供用于此类目的的数据字段，我也使用一些邪恶的摆弄C代码。它涉及通过设置最高有效位（我从未使用过）来使用元素本身的内存，以标记经过的元素。那是很粗略的，除非您确实在接近装配水平上工作，否则不要这样做，而只是想提一下，即使在元素不能提供特定于遍历的字段的情况下，如果可以保证的话，该方法如何适用。某些位将永远不会被使用。在我的dinky i7上，它可以在不到一秒钟的时间内计算出2亿个元素（约2.4个千兆字节的数据）之间的设定交集。尝试在两个同时std::set包含一亿个元素的实例之间进行设置交集；甚至没有接近。
那边...
但是，我也可以通过将每个elemento添加到另一个向量并检查该元素是否已经存在来做到这一点。
检查新矢量中是否已经存在元素的检查通常将是线性时间操作，这将使交集本身成为二次操作（爆炸性工作量越大，输入大小越大）。如果您只想使用简单的旧向量或数组并以可扩展的方式进行操作，那么我建议您使用上述技术。
基本上：哪种算法需要一个集合，而其他任何容器类型都不应该完成？
如果您问我的偏见是否在容器级别谈论（例如，在专门为有效提供设置操作而实现的数据结构中），则没有任何问题，但是有很多要求在概念级别使用设置逻辑。例如，假设您想在游戏世界中找到既能飞行又能游泳的生物，并且您有一组飞行的生物（无论您是否实际使用了一组容器），又有一组可以游泳的生物。 。在这种情况下，您需要设置交点。如果您想要可以飞行或具有魔法的生物，则可以使用固定联合。当然，您实际上不需要设置容器来实现此目的，并且最佳优化实现通常不需要或不希望将容器专门设计为集合。
切线
好的，我从JimmyJames那里得到了一些关于此交集方法的很好的问题。这有点偏离主题，但是，我希望看到更多的人使用这种基本的侵入式方法来设置交集，以便他们不仅仅为了设置操作的目的而构建诸如平衡二叉树和哈希表之类的整个辅助结构。如前所述，基本要求是列出浅表复制元素，以便它们索引或指向共享元素，该共享元素可以通过第一个未排序的列表或数组或随后在第二个未排序的列表中传递的内容进行“标记”通过第二个列表。
但是，即使在多线程上下文中，只要不满足以下条件，就可以实际完成此操作：
- 这两个集合包含元素的索引。
- 索引的范围不会太大（例如[0，2 ^ 26]，不是十亿或更多），并且被合理地密集占用。
这使我们可以使用并行数组（每个元素仅一位）来进行设置操作。图解：
仅当从池中获取并行位数组并将其释放回池时才需要线程同步（超出范围时隐式完成）。执行设置操作的实际两个循环不需要任何线程同步。如果线程只可以在本地分配和释放位，我们甚至不需要使用并行位池，但是位池可以方便地在适合此类数据表示的代码库中概括模式，在这种情况下，经常引用中央元素按索引，这样每个线程都不必担心高效的内存管理。我所在领域的主要示例是实体组件系统和索引网格表示。两者都经常需要设置交集，并且倾向于引用集中存储的所有内容（ECS中的组件和实体以及顶点，边，
如果索引没有被密集地占用和稀疏地散布，那么这仍然适用于并行位/布尔数组的合理稀疏实现，例如仅以512位块（每个展开的节点64个字节代表512个连续索引）存储内存的情况。 ），并跳过分配完全空闲的连续块。如果您的中央数据结构很少被元素本身占用，那么您很有可能已经在使用这样的东西。
...稀疏位集用作并行位数组的类似想法。这些结构也很容易实现不变性，因为浅层复制块状块很容易，不需要进行深层复制即可创建新的不可变拷贝。
使用这种方法，在一台非常普通的机器上，可以在一秒钟之内完成数亿个元素之间的相交设置，而这仅在一个线程内。
如果客户端不需要用于结果交集的元素列表，也可以在不到一半的时间内完成，例如如果客户只想对两个列表中的元素应用某种逻辑，此时他们可以通过函数指针，函子或委托或将被调用以返回相交元素范围的任何内容。达到此效果的方法：
// 'func' receives a range of indices to
// process.
set_intersection(func):
{
parallel_bits = bit_pool.acquire()
// Mark the indices found in the first list.
for each index in list1:
parallel_bits[index] = 1
// Look for the first element in the second list
// that intersects.
first = -1
for each index in list2:
{
if parallel_bits[index] == 1:
{
first = index
break
}
}
// Look for elements that don't intersect in the second
// list to call func for each range of elements that do
// intersect.
for each index in list2 starting from first:
{
if parallel_bits[index] != 1:
{
func(first, index)
first = index
}
}
If first != list2.num-1:
func(first, list2.num)
}
...或达到这种效果的东西。第一个图中伪代码最昂贵的部分是intersection.append(index)在第二个循环中，即使std::vector事先保留了较小列表的大小，这也适用。
如果我复制所有内容该怎么办？
好吧，别说了！如果需要设置相交，则意味着您正在复制数据以进行相交。甚至您最细小的对象都有可能不小于32位索引。除非您实际上需要实例化超过43亿个元素，否则很有可能将元素的寻址范围减小到2 ^ 32（2 ^ 32个元素，而不是2 ^ 32字节），此时需要一个完全不同的解决方案（而这绝对不是在内存中使用set容器）。
关键比赛
在需要元素不相同但可能具有匹配键的设置操作的情况下呢？在这种情况下，与上述相同。我们只需要将每个唯一键映射到索引。例如，如果键是字符串，则实习字符串可以做到这一点。在这些情况下，需要一个很好的数据结构（例如trie或哈希表）将字符串键映射到32位索引，但是我们不需要这种结构即可对所得的32位索引进行设置操作。
当我们可以在非常合理的范围内（而不是在机器的全部寻址范围内）对元素的索引进行操作时，就会出现许多非常便宜且直接的算法解决方案和数据结构，就像这样，这通常是值得的能够为每个唯一键获取唯一索引。
我喜欢指数！
我喜欢指数，就像比萨饼和啤酒一样。在我20多岁的时候，我真正地开始使用C ++，并开始设计各种完全符合标准的数据结构（包括在编译时消除范围ctor歧义的技巧）。回想起来，这是浪费大量时间。
如果围绕数据库将元素集中存储在数组中并对其进行索引，而不是将它们存储在整个机器可寻址范围内的零散的方式中，那么您最终可能会探索算法和数据结构的可能性，设计围绕旧的int或旧的容器和算法int32_t。而且我发现最终结果更加高效并且易于维护，因为我不必不断地将元素从一种数据结构转移到另一种数据结构再转移到另一种数据结构。
一些示例用例，当您可以假设的任何唯一值都T具有唯一索引，并且实例驻留在中央数组中时：
多线程基数排序可以很好地与索引的无符号整数配合使用。我实际上有一个多线程基数排序，大约需要1/10的时间来排序1亿个元素，这是Intel自己的并行排序，而Intel的速度已经比std::sort这么大的输入快4倍。当然，英特尔的灵活性更高，因为它是一种基于比较的排序，并且可以按字典顺序对事物进行排序，因此它可以将苹果与桔子进行比较。但是在这里，我通常只需要橘子，就像我可能要进行基数排序一样，以实现对缓存友好的内存访问模式或快速过滤出重复项。
无需链接节点的堆分配即可构建链接结构（如链接列表，树，图形，单独的链式哈希表等）的能力。我们可以批量分配与元素平行的节点，然后将它们与索引链接在一起。节点本身只是成为下一个节点的32位索引，并存储在一个大数组中，如下所示：
便于并行处理。通常，链接结构对并行处理不太友好，因为至少要在树或链接列表遍历中实现并行性相对于仅通过数组进行并行for循环是很尴尬的。使用索引/中心数组表示，我们始终可以转到该中心数组，并在大块并行循环中处理所有内容。即使我们只想处理某些元素，我们也始终拥有一个可以通过这种方式处理的所有元素的中央数组（此时，您可以处理由基数排序的列表索引的元素，以便通过中央数组进行缓存友好的访问）。
可以将数据实时关联到每个元素。与上面的并行位数组的情况一样，我们可以轻松便宜地将并行数据与元素关联起来，例如进行临时处理。除了临时数据外，还有一些用例。例如，网格系统可能希望允许用户根据需要将尽可能多的UV贴图附加到网格上。在这种情况下，我们不能仅仅使用AoS方法硬编码每个顶点和面中将有多少UV贴图。我们需要能够即时关联此类数据，并且并行数组在那里很方便，并且比任何种类的复杂关联容器（甚至是哈希表）便宜得多。
当然，并行阵列由于易于出错的性质而使并行阵列彼此保持同步，因此人们对此并不满意。例如，每当我们从“根”数组中删除索引7中的元素时，我们同样都必须对“子项”执行相同的操作。但是，在大多数语言中，将这个概念推广到通用容器是很容易的，因此，使并行数组彼此保持同步的棘手逻辑只需要存在于整个代码库的一个位置，这样的并行数组容器就可以请使用上面的稀疏数组实现来避免浪费大量内存，以便在后续插入时回收数组中的连续空闲空间。
详细说明：稀疏位集树
好吧，我收到了详细说明一些我认为很讽刺的请求，但无论如何我还是会这样做的，因为它是如此的有趣！如果人们想将这个想法带到一个全新的高度，那么就可以执行设置的相交而无需线性地循环遍历N + M个元素。这是我使用了很长时间的基本数据结构，并且基本上是模型set<int>：
它甚至不检查两个列表中的每个元素就可以执行集合交集的原因是因为层次结构根部的单个集合位可以指示，例如，一百万个连续元素被占用了集合。仅检查一位，就可以知道该范围内的N个索引在[first,first+N)集合中，其中N可以是一个非常大的数字。
在遍历占用的索引时，我实际上将其用作循环优化器，因为假设集合中有800万个索引。好吧，在这种情况下，通常我们必须访问800万个整数。有了它，它可以潜在地只检查几位并提出占用索引的索引范围进行循环。此外，它带来的索引范围是按排序顺序进行的，这使得缓存非常友好，可以进行顺序访问，而不是例如遍历用于访问原始元素数据的未排序索引数组。当然，这种技术在极端稀疏的情况下会变得更糟，最坏的情况是每个索引都是偶数（或者每个索引都是奇数），在这种情况下，没有连续的区域。但是至少在我的用例中，
