解释对 GNU C++ 的更改filebuf::underflow() 与 filebuf::seekoff() 交互

Question

我公司的产品在许多合格的 Linux 硬件/软件配置上运行。历史上，使用的编译器是 GNU C++。出于本文的目的，我们将 3.2.3 版本视为基准，因为我们的软件在该版本中“按预期工作”。

随着使用 GNU C++ 版本 3.4.4 的更新的合格平台的引入，我们开始观察到一些我们以前没有见过的性能问题。经过一番挖掘，我们的一位工程师想出了这个测试程序：

#include <fstream>
#include <iostream>

using namespace std;

class my_filebuf : public filebuf
{
public:

   my_filebuf() : filebuf(), d_underflows(0) {};
   virtual ~my_filebuf() {};

   virtual pos_type seekoff(off_type, ios_base::seekdir,
                            ios_base::openmode mode = ios_base::in | ios_base::out);

   virtual int_type underflow();

public:
   unsigned int d_underflows;
};

filebuf::pos_type my_filebuf::seekoff(
   off_type           off,
   ios_base::seekdir  way,
   ios_base::openmode mode
)
{
   return filebuf::seekoff(off, way, mode);
}

filebuf::int_type my_filebuf::underflow()
{
   d_underflows++;

   return filebuf::underflow();
}

int main()
{
   my_filebuf fb;
   fb.open("log", ios_base::in);
   if (!fb.is_open())
   {
      cerr << "need log file" << endl;
      return 1;
   }

   int count = 0;
   streampos pos = EOF;
   while (fb.sbumpc() != EOF)
   {
      count++;

      // calling pubseekoff(0, ios::cur) *forces* underflow
      pos = fb.pubseekoff(0, ios::cur);
   }

   cerr << "pos=" << pos << endl;
   cerr << "read chars=" << count << endl;
   cerr << "underflows=" << fb.d_underflows << endl;

   return 0;
}

我们针对大约 751KB 字符的日志文件运行它。在之前的配置中，我们得到的结果是：

$ buftest
pos=768058
read chars=768058
underflows=0

在新版本中，结果是：

$ buftest
pos=768058
read chars=768058
underflows=768059

注释掉 pubseekoff(0, ios::cur) 调用和过多的 underflow() em> 来电消失。很明显，在较新版本的 g++ 中，调用 pubseekoff() 会使缓冲区“无效”，从而强制调用 underflow()。

我已经阅读了标准文档，并且 pubseekoff() 上的措辞肯定是不明确的。例如，底层文件指针位置与 gptr() 的位置有什么关系？在调用 underflow() 之前还是之后？不管怎样，可以这么说，我觉得 g++“中途换马”很令人恼火。此外，即使通用 seekoff() 需要使缓冲区指针无效，为什么要使用 ftell() 的等效项呢？

谁能向我指出导致这种行为变化的实现者之间的讨论线程？您对所涉及的选择和权衡有简洁的描述吗？

额外的学分

显然我真的不知道我在做什么。我正在尝试确定是否有一种方法（但不可移植）在 offset 为 0 且eekdir 为 ios::cur 的情况下绕过失效。我想出了以下 hack，直接访问 filebuf 数据成员 _M_file （这只想在我的机器上使用 3.4.4 版本进行编译）：

int sc(0);
filebuf::pos_type my_filebuf::seekoff(
   off_type           off,
   ios_base::seekdir  way,
   ios_base::openmode mode
)
{
   if ((off == 0) && (way == ios::cur))
   {
      FILE *file =_M_file.file();
      pos_type pos = pos_type(ftell(file));

      sc++;
      if ((sc % 100) == 0) {
         cerr << "POS IS " << pos << endl;
      }

      return pos;
   }

   return filebuf::seekoff(off, way, mode);
}

但是，诊断每一百次 seekoff 尝试打印出位置，每次都会产生 8192。啊？由于这是 filebuf 本身的 FILE * 成员，我希望它的文件位置指针与任何 同步filebuf 进行的 underflow() 调用。为什么我错了？

更新

首先，让我强调一下，我明白我的帖子的后半部分都是关于不可移植的黑客。尽管如此，还是不​​明白这里的实质内容。我尝试拨打电话

pos_type pos = _M_file.seekoff(0,ios::cur);

，这高兴通过示例文件进行，而不是陷入 8192。

最终更新

在我的公司内部，我们制定了一些解决方法，以减少我们可以承受的性能损失与它。

在外部，David Krauss 针对 GNU 的 libstdc++ 流提交了一个 bug，最近，保罗·卡利尼 (Paolo Carlini) 检查了修复。共识是，不良行为在标准的范围内，但对于我描述的边缘情况有一个合理的修复。

感谢 StackOverflow、David Krauss、Paolo Carlini 和所有 GNU 开发人员！

Answer 1

seekoff 的要求确实令人困惑，但 seekoff(0, ios::cur) 应该是一种不同步任何内容的特殊情况。所以这可能被认为是一个错误。

在 GCC 4.2.1 和 4.5 中仍然会发生这种情况……

问题是 (0, ios::cur) 在 _M_seek 中不是特殊情况，它 eekoff 用于调用fseek 来获取其返回值。只要成功，_M_seek就会无条件调用_M_set_buffer(-1);，这可以预见地使内部缓冲区无效。下一个读取操作会导致下溢。

找到差异！请参阅更改-473,41 +486,26。评论是，

    (seekoff): Simplify, set _M_reading, _M_writing to false, call
    _M_set_buffer(-1) ('uncommitted').

所以这并不是为了修复错误。

提交的错误： http://gcc.gnu.org/bugzilla/show_bug.cgi ?id=45628

Answer 2

好吧，我不知道更改的确切原因，但显然更改是为了（请参阅 GCC 3.4系列变更日志)：

• 精简streambuf、filebuf，与C标准I/Ostreambuf单独同步。
• 大文件支持（32 位系统上大于 2 GB 的文件）。

我怀疑大文件支持是需要进行这样的更改的重要功能，因为 IOStreams 不能再假设它可以将整个文件映射到内存中。

与 cstdio 正确同步也是一项可能需要大量刷新磁盘的操作。您可以使用 std::sync_with_stdio。