【问题标题】:C++ doubling index vector of unique ordered relationships唯一有序关系的 C++ 加倍索引向量
【发布时间】:2018-07-14 03:37:38
【问题描述】:

我正在寻找一个标准风格的容器,即带有迭代器等带有 结构如下:

template <hashable T, hasable U> class relationships {
    relation(std::[vector or list]<std::pair<T,U>> list);
    const std::pair<T,U>& operator [](const T index);
    const std::pair<T,U>& operator [](const U index);
}

这是一个双向映射,成对的顺序列表,T 和 U 的每个值都是唯一的,并且都是可散列的,并且相关的 T 和 U 对具有特定的顺序,应该通过以下循环重现

for (auto it : relationships) {
    // do something with it
}

相当于

for (auto it : list) {
    // do something with it
}

我还想要高效的查找,即运算符 [],对于这两种类型都应该等效于 std::unorderd_map。

最后我正在寻找基于标准库的解决方案,使用 C++14 并且不想使用 BOOST。

我之前看到了如何使用二叉搜索树实现哈希映射,但是我正在寻找有关如何有效维护两个索引和有序元素的结构的见解,或者现有解决方案(如果存在的话):

我目前的想法是使用沿线的节点

template <typename T, typename U> struct node {
    std::pair<T, U> value; // actual value
    // hashs for sorting binary trees
    size_t hashT;
    size_t hashU;
    // linked list for ordering
    node * prevL;
    node * nextL;
    // binary search tree for type T lookup
    node * parentT;
    node * prevT;
    node * nextT;
    // binary search tree for type U lookup
    node * parentU;
    node * prevU;
    node * nextU;
}

但是这种接缝效率很低

我的另一个想法是存储一个或多个具有顺序的向量,然后存储std::pair&lt;size_t, size_t&gt; 的两个排序索引向量,第一个是哈希,第二个是索引,但是我应该如何处理执行二进制搜索索引向量并处理哈希冲突。我相信这个解决方案会更节省内存和类似的速度,但不确定所有实现细节。

编辑:我不需要快速插入,只需查找和迭代,映射将生成一次,然后用于查找关系。

【问题讨论】:

  • 如果你想要性能,你想要什么快:迭代、搜索还是插入?基本上大多数时候,您的新数据结构都基于向量,或者在极少数情况下,基于哈希图。 Vector 是快速迭代、快速插入和快速搜索,如果它们构造得很好,那么您就可以对它们进行排序。如果您在两次搜索之间不断插入元素,Hashmap 的搜索速度会更快。

标签: vector hashmap mapping c++14 c++-standard-library


【解决方案1】:

关于性能,这完全取决于算法以及您尝试使用的 T 和 U 的类型。如果您构建数据然后不更改它,一个简单的解决方案如下:

  1. 使用vector&lt;pair&lt;T,U&gt;&gt; 构建您的数据
  2. 复制此向量
  3. 一个向量按照T排序,一个按照U排序
  4. 使用二分查找进行快速查找,如果按 T 查找,则在第一个向量中,如果按 U 查找,则在第二个向量中
  5. 将所有这些隐藏在构造/排序/访问接口后面。您可能不想使用operator[],因为您只需要在排序后查看数据结构

当然,就复制数据而言,该解决方案并不完美。但是,请记住,您不会像使用 hashmap 那样有额外的隐藏分配。例如,对于 T = U = int,我认为使用的内存不会超过 std::unordered_map,因为每个节点都需要存储一个指针。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-02-20
    • 2011-06-14
    • 1970-01-01
    • 2020-03-26
    • 1970-01-01
    • 2021-11-18
    • 2015-07-01
    相关资源
    最近更新 更多