std::iostream 不能直接做双向管道通信，因其是抽象接口，依赖的 streambuf 子类才决定数据流向；普通 filebuf 不支持同时读写同一 pipe fd，且 POSIX FIFO 要求单向端点，需自定义 streambuf 封装双 fd 才能实现。
为什么 std::iostream 本身不能直接做双向管道通信
因为 std::iostream 是抽象接口，不绑定具体设备类型；它背后依赖的 std::streambuf 子类才决定数据流向。普通文件流（如 std::ifstream/std::ofstream）是单向的，底层 filebuf 不支持同时读写同一内核 pipe fd —— 这不是 C++ 标准库的设计目标，而是系统级能力。
常见错误现象：std::fstream 打开命名管道（FIFO）后调用 read() 卡住、write() 失败返回 -1、或抛出 ios_base::failure 异常，根本原因是底层 pipe(2) 文件描述符未被正确封装进可读写 streambuf。
- Unix 命名管道（FIFO）必须一端只读、一端只写，不能像 socket 那样全双工
-
std::fstream构造时传入std::ios::in | std::ios::out对 FIFO 无效，内核会拒绝open(O_RDWR) - Windows 的
CreateNamedPipe支持双向句柄，但标准库 streambuf 没有对应实现
用 std::streambuf 包装 pipe(2) 实现双向缓冲（Linux/macOS）
核心思路：绕过 std::fstream，自己继承 std::streambuf，把一对 pipe fd（pipefd[0] 读端、pipefd[1] 写端）塞进去，重写 underflow() 和 overflow()。
关键点在于：不能共用一个 fd，必须用两个独立 fd 组成“伪双向流”——读操作走 pipefd[0]，写操作走 pipefd[1]，这符合 POSIX pipe 语义。
- 构造时调用
pipe(pipefd)，确保pipefd[0]可读、pipefd[1]可写 -
underflow()中用read(pipefd[0], ...)填充输入缓冲区（setg(...)） -
overflow()中用write(pipefd[1], ...)刷出输出缓冲区 - 记得在析构里
close(pipefd[0])和close(pipefd[1])，否则资源泄漏
示例片段：
class pipebuf : public std::streambuf {
int pipefd[2];
protected:
int underflow() override {
if (gptr() && gptr() 0) setg(in_buffer, in_buffer, in_buffer + n);
return n > 0 ? traits_type::to_int_type(*gptr()) : traits_type::eof();
}
int overflow(int c) override {
if (c != traits_type::eof()) {
char ch = traits_type::to_char_type(c);
write(pipefd[1], &ch, 1);
}
return traits_type::not_eof(c);
}
public:
pipebuf() { pipe(pipefd); }
~pipebuf() { close(pipefd[0]); close(pipefd[1]); }
private:
char in_buffer[1024];
};
如何让 std::iostream 关联这个自定义 streambuf
只要把你的 pipebuf 实例地址传给 std::iostream 构造函数，它就自动接管读写逻辑。注意：不要用 std::cin/std::cout 去关联，它们已绑定到终端，改不了。
- 创建方式：
pipebuf pb; std::iostream io(&pb); - 之后所有
io 走 <code>overflow()，io >> x或io.get()走underflow() - 若需兼容
std::istream/std::ostream分离使用，得拆成两个streambuf实例（各持一个 fd），再分别构造 - 别忘了设
io.exceptions(std::ios::badbit)，否则read/write错误会被静默吞掉
Windows 下用 CreateNamedPipe 替代的注意事项
Windows 命名管道支持真正的双向句柄（PIPE_ACCESS_DUPLEX），但标准库没有现成 streambuf 封装。你得自己实现，且必须处理同步模型差异：
- Win32 管道默认是阻塞的，但建议用
FILE_FLAG_OVERLAPPED+ IOCP，否则underflow()可能永久挂起 -
ReadFile/WriteFile返回值和 errno 语义与 POSIX 不同，需检查GetLastError() - 不能直接复用 Linux 版
pipebuf，因为 Windows 管道句柄不是整数 fd，要转成_open_osfhandle才能塞进某些 libc 实现 —— 但这是不可靠的 hack，MSVC 的std::filebuf不吃这套 - 更稳妥的做法：放弃
std::iostream，直接用ReadFile/WriteFile+ 自定义缓冲区，或者换用 Boost.Iostreams
真正容易被忽略的是：跨平台代码里，pipe 的生命周期管理比流对象更早、更底层。一旦父进程 fork 后没关掉冗余 fd，子进程可能永远等不到 EOF —— 这跟 C++ 语法无关，是系统编程的基本直觉。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
