c++ - boost::any_range 和运算符 []

Question

考虑以下代码:

#include <boost/range.hpp>
#include <boost/range/any_range.hpp>
#include <boost/range/join.hpp>

#include <iostream>
#include <algorithm>
#include <string>
#include <vector>
#include <list>

struct TestData {
  TestData() : m_strMem01("test"), m_intMem02(42), m_boolMem03(true) {}
  std::string m_strMem01;
  int m_intMem02;
  bool m_boolMem03;
};

struct IntComp {
  bool operator()(const TestData &s, int i) { return s.m_intMem02 < i; }
  bool operator()(int i, const TestData &s) { return i < s.m_intMem02; }
  bool operator()(const TestData &i, const TestData &s) {
    return i.m_intMem02 < s.m_intMem02;
  }
};
struct StrComp {
  bool operator()(const TestData &s, const std::string &str) {
    return s.m_strMem01 < str;
  }
  bool operator()(const std::string &str, const TestData &s) {
    return str < s.m_strMem01;
  }
  bool operator()(const TestData &i, const TestData &s) {
    return i.m_strMem01 < s.m_strMem01;
  }
};

typedef boost::any_range<TestData, boost::forward_traversal_tag,
                         const TestData &, std::ptrdiff_t> TestRange;

std::vector<TestData> vecData(10);
std::list<TestData> listData(20);

TestRange foo() {
  TestRange retVal;

  auto tmp1 = std::equal_range(vecData.cbegin(), vecData.cend(), 42, IntComp());
  retVal = boost::join(retVal, tmp1);
  auto tmp2 =
      std::equal_range(listData.cbegin(), listData.cend(), "test", StrComp());
  retVal = boost::join(retVal, tmp2);
  return retVal;
}

int main(int argc, char *argv[]) {
  auto res = foo();
  for (auto a : res) {
    std::cout << a.m_strMem01 << std::endl;
  }
  //std::cout << res[4].m_intMem02 << std::endl;
}

如果您取消注释最后一行，代码将失败，因为 distance_to 没有为 any_forward_iterator_interface 实现。我不确定我到底错过了什么，比如实现 operator[] 或 distance_to 但为了什么？我自己的版本遍历标签？为什么它一开始就不起作用？

Coliru version

Answer 1

我会说答案取决于您的性能需求和您在实现新的迭代器抽象时的惰性。 [] 运算符不起作用的核心原因是 std::list<...> 不提供随机访问遍历迭代器。如果您选择了提供此类迭代器的容器。您 any_range<...> 可以采用 random_access_traversal_tag 并且一切都会好起来的。我认为可以公平地说，通过简单地封装当前索引并在要访问特定位置时在列表中向前和向后计数来在列表顶部实现随机访问迭代器并不是什么大不了的事情，但是这显然违背了列表性能的本质。

• 是否有充分的理由将其中一个集合放在列表中？
• 随机访问生成的 any_range 是否有充分的理由？
• 是否值得为 std::list 提供一个低效的随机访问接口(interface)？