基于范围for循环的TAR归档迭代实现：tar_fs::end()如何实现？

现有设计的核心矛盾 #

当前迭代器的相等判断逻辑为硬比对底层指针是否完全相等，如果要返回一个持有实际块指针的 tar_iterator 作为 end，就必须提前从归档起始位置遍历到终止块、记录终止块的内存地址，本质上绕不开全量预扫描，和“不预先统计文件总数、不提前遍历全量归档”的需求冲突。

核心实现思路 #

借助无状态哨兵迭代器替代固定指针类型的 end，完全不需要预扫描即可支持范围 for 循环。C++17 起的范围 for 语法不要求 begin 和 end 是完全相同的类型，只要两者可做不等判断即可。

具体改造步骤 #

• 定义无状态的终止哨兵类型
  不需要任何成员变量，仅作为循环终止的标记使用：

  struct tar_end_sentinel {};
  

• 给 tar_iterator 增加和哨兵的比较逻辑
  只要迭代器当前没有有效指向、或是指向的块是终止块，就判定到达循环终点。原有两个普通迭代器的指针相等判断逻辑完全保留，不会破坏已有功能：

  // 追加到 tar_iterator 的类定义中
  bool operator==(const tar_end_sentinel&) const noexcept {
      return m_header == nullptr || m_header->is_terminator();
  }
  // C++20 起编译器会自动生成配套的 != 运算符，低版本可手动补全
  bool operator!=(const tar_end_sentinel& sentinel) const noexcept {
      return !(*this == sentinel);
  }
  

• 补全 tar_fs::end() 的实现
  直接返回哨兵实例即可，不需要任何指针计算、不需要预扫描：

  tar_end_sentinel end( void ) {
      return {};
  }
  

缺失的必要接口补全 #

要让迭代器正常工作，还需要把现有框架中未实现的核心逻辑补全：

• 实现 tar::header::next() 方法
  该方法是迭代器自增的核心，负责跳转到下一个文件的头部块位置：

  class header {
  public:
      bool is_terminator( void ) { /* 现有全0块判断逻辑 */ }
      header* next() {
          // 遇到终止块直接返回空指针，标记到达终点
          if (is_terminator()) return nullptr;
          // 从头部字段解析当前文件的实际大小
          size_t file_size = parse_header_file_size();
          // 计算需要跳过的总块数：1个头部块 + 向上取整的512B数据块
          size_t total_offset_blocks = 1 + ((file_size + 511) / 512);
          // 按块偏移计算下一个头部的地址
          return reinterpret_cast<header*>(
              reinterpret_cast<char*>(this) + total_offset_blocks * 512
          );
      }
  private:
      size_t parse_header_file_size(); // 解析TAR头中的文件大小字段
  };
  

• 补全解引用运算符 operator*()
  每个头部块的紧跟位置就是对应文件的首个数据块，直接偏移1个512B块即可拿到数据区起始地址：

  tar::data * operator*( void ) const noexcept {
      return reinterpret_cast<tar::data*>(
          reinterpret_cast<char*>(m_header) + 512
      );
  }
  

方案对比 #

如果坚持要让 tar_fs::end() 返回和 begin 同类型的 tar_iterator，可采用延迟缓存方案：第一次调用 end() 时才从归档起点遍历到终止块，把终止块位置存在成员变量中，后续调用直接返回缓存值。

• 该方案的缺点是：第一次触发 end 调用时会强制全量扫描整个归档，哪怕用户只需要读取第一个文件就退出，也会产生不必要的内存访问开销，不如哨兵方案灵活。

内容的提问来源于stack exchange，提问作者Martin Kopecký