问题标签 [filebuf]

我在这里读到，对于输入缓冲区，filebuf::sync's：

效果 - 如果有的话 - 取决于库实现

那么我的问题是，谁能告诉我这些对 gcc 和 Visual Studio 的影响是什么？

我正在研究操纵 stringbuf 的函数，我需要将其保存在文件中。如果我可以将 stringbuf 直接传递给 ofstream 的 filebuf，那将是一个巨大的优势。

我知道两者都使用streambuf对象而不是我可以以某种方式将filebuf的streambuf替换为我的stringbuf的流吗？

查看下面的代码以更好地理解这个想法：

我正在尝试自动打印从 cin 获取输入的每个变量。

这是我的流课程。比我尝试将 cin 缓冲区设置为 MyFileStream 缓冲区，但函数 xsgetn 甚至没有被调用一次的问题。我该如何解决？如果我尝试对输出流执行相同的操作，则使用 xsputn 它可以工作并调用该函数。

我这样做是因为我希望输出流也包含输入流，并且我可以获得整个控制台内容。也许还有另一种解决方案？

请检查以下代码：

运行此程序后，没有数据写入文件，而sputn->n正在返回有效数量的 writtne 字符（通过调试验证）。

我有一些用于std::ifstream从文件中读取的代码，但不使用std::ifstream. 它本质上是这样的：

由于我直接处理文件中的原始字节，因此它似乎更适合使用std::filebuf而不是std::ifstream：

从表面上看，这两个代码片段可能实现了相同的结果。然而，在检查 C++ 参考资料后，std::basic_istream::read()说：

如果内部操作抛出异常，则会被捕获并设置 badbit。如果为 badbit 设置了 exceptions()，则重新抛出异常。

由于badbit用于指示底层文件由于某种原因已损坏（可能操作系统无法再访问该文件），因此std::ifstream代码片段似乎将通过跳出循环来处理这种可能性（good()将返回false）。

但是，std::basic_streambuf::sgetn()并没有说明底层文件变得不可访问的可能性。它也没有提到抛出任何异常的可能性（但它没有标记为noexcept）。

有没有办法在使用std::filebuf时正确处理文件过早无法访问（即尚未 EOF）的情况？（或者，我对文件 I/O 的理解是错误的？）

页面std::basic_filebuf::sync()说

sync()或其等价物由 ... 隐式调用seekoff()，并且seekpos()...

但我似乎在语言规范中找不到任何提及，无论是here还是here。

我对两者的规范部分的阅读是filebuf，甚至不清楚它们是否有效地完成了所做的事情（以及他们要做的其他事情），更不用说调用它或它的等价物了。seekoff()seekpos()sync()

cppreference上的这个措辞是否具有误导性？

我正在尝试使用 ostream 对象写入基于字符串流的用户输入的文件流（类似于fmemopenLinux）。

我意识到 ostream 不采用 stringstream 或 fstream 对象，而是采用 stringbug 或 filebuf。

我尝试了以下代码：

这在 if else 条件下工作正常，但我想在 if else 条件之外使用ostream os, as os << content。但是问题是我无法全局定义 ostream os，因为 ostream 没有这样的构造函数。

有没有办法解决这个问题？

我有一个 c++ 应用程序，它有多个无限运行的守护线程，它执行一些文件记录和轮换。

此应用程序在使用 VS2010 编译时运行良好。但是当我使用 VS 2017 升级和编译它时，这两个线程之间发生了一个奇怪的死锁，导致应用程序冻结。

我用windbg分析了exe的转储。这是两个线程的堆栈。

超出！锁。显示有死锁。

这是执行的代码

上面的代码专门在这两个线程中执行，因为这个定义是单独的 dll 的一部分。

转储中的堆栈跟踪显示我的代码中的最后一个函数是 do_open() 函数。这段代码在 std::fileuf 上调用 open 函数

这种死锁或冻结是如何在系统级别发生的？

有人可以对此提供一些见解吗？

在实施basic_filebuf时我偶然发现basic_filebuf::pbackfail并且不完全理解它的定义。

来自cplusplus.com

或来自cppreference：

所以本质上两者都说输入位置递减（除非它在文件的开头）并且可能放回一个字符。所以以下应该成功（假设根据注释准备文件，使用标准类来比较行为）：

然而，在 libc++ 上，第一次回退已经失败，并检查我发现pbackfail由if (__file_ && this->eback() < this->gptr())aka 保护的源代码“如果有一个打开的文件并且当前读取缓冲区的前面有空间”。

刷新/同步/搜索清除读取缓冲区，这解释了失败的放回。当使用无缓冲 IO 时，读取缓冲区中只有一个字符空间，因此（至少）第二次放回即使没有刷新也会失败。或者第二次获取可能会跨越缓冲区“边界”，这意味着“b”将是当前缓冲区中的第一个字符，这也会导致第二次回退失败。

问题：如何准确指定回退？尽管 cppreference 和 cplusplus 似乎都暗示读取位置在任何情况下都会递减，但它似乎仅在 get 后立即有效。如果他们是对的，是 libc++ 不符合标准还是我遗漏了什么？

我想打开一个文件进行读写std::filebuf，但如果该文件尚不存在，则创建该文件。如果它已经存在，什么也不做。我想自由地写入文件，没有任何“每次写入前总是跳到结尾”的行为。应该使用什么开放模式？

根据表格，似乎没有标志组合可以做到这一点。

确保这种效果的最佳选择是什么？