C++ I/O 设计中的"分离"思想 —— 为什么好的 I/O 代码从不把事情搅在一起

为什么 std::cout << "x=" << x 慢得离谱？为什么 std::fstream 既能读文件又能做格式化还能管缓冲？为什么高并发网络库（muduo / libevent / asio）从来不让你"读写套接字的同时解析业务协议"？本篇从 C++ 标准库到高性能网络框架，系统论述 I/O 设计里反复出现的**分离（Separation of Concerns）**思想，并逐类解剖标准库中每一层的职责、接口和设计动机。

更新时间：2026-08-06

零、C++ I/O 类层次全景

在讨论分离思想之前，先理清 C++ 标准库 I/O 的完整类继承关系。整个体系围绕一条核心拆分原则组织：上层流类（template <charT, traits>）负责"数据含义"（格式化、解析、类型转换），下层缓冲类（basic_streambuf）负责"字节搬运"（缓冲、系统调用、设备交互）。

0.1 模板层次：<charT, traits> 实參化全景

0.2 typedef 特化：char 和 wchar_t 两张门面

C++ 标准只做了两个实例化，所有用户代码都通过 typedef 使用：

0.3 类职责速查表（全量）

类	所在层次	核心职责	持有缓冲？	与设备交互？
ios_base	流状态基类	格式状态（flags/precision/width）、流状态（iostate）、locale、异常回调、静态初始化	否	否
basic_ios<charT,traits>	流抽象	持有 basic_streambuf*，提供 tie() 机制、异常屏蔽	否	否
basic_istream<charT,traits>	输入层	operator>>、get/getline/read/peek/ignore、seekg/tellg	否，委托 streambuf	否
basic_ostream<charT,traits>	输出层	operator<<、put/write、flush、seekp/tellp	否，委托 streambuf	否
basic_iostream<charT,traits>	组合层	同时继承 istream + ostream	否	否
basic_ifstream<charT,traits>	文件输入流	继承 istream + 内嵌 basic_filebuf	是	是（文件）
basic_ofstream<charT,traits>	文件输出流	继承 ostream + 内嵌 basic_filebuf	是	是（文件）
basic_fstream<charT,traits>	文件读写流	继承 iostream + 内嵌 basic_filebuf	是	是（文件）
basic_istringstream<charT,traits>	字符串输入流	继承 istream + 内嵌 basic_stringbuf	是	是（内存 string）
basic_ostringstream<charT,traits>	字符串输出流	继承 ostream + 内嵌 basic_stringbuf	是	是（内存 string）
basic_stringstream<charT,traits>	字符串读写流	继承 iostream + 内嵌 basic_stringbuf	是	是（内存 string）
basic_streambuf<charT,traits>	缓冲抽象	六个指针管理 put area / get area，虚函数 overflow/underflow/sync	管缓冲	是，通过虚函数
basic_filebuf<charT,traits>	文件缓冲	open/close，OS fd 的全缓冲/行缓冲/无缓冲	是	是（OS fd）
basic_stringbuf<charT,traits>	字符串缓冲	str() 存取内部 std::basic_string	是	是（内存）
basic_strstreambuf<charT,traits>	字符数组缓冲（废弃）	freeze/str，new char[] 动态分配	是	是（堆内存）
ostreambuf_iterator<charT,traits>	输出迭代器	封装 streambuf::sputc() 为输出迭代器接口	否	间接
istreambuf_iterator<charT,traits>	输入迭代器	封装 streambuf::sgetc() 为输入迭代器接口	否	间接

ios_base 与 basic_ios 为什么分开？因为 basic_istream 和 basic_ostream 需要共享同一个格式化状态（flags、locale 等），但菱形继承时不能各存一份。ios_base 作为虚基类，只存格式化状态和流错误标志；basic_ios 负责持有 basic_streambuf* 指针。这样 basic_iostream（同时继承 istream 和 ostream）不会产生两套状态。

一、ios_base：流的"元数据管家"

ios_base 是整个继承体系的最底层，不持有任何缓冲区指针，也不做任何 I/O。它只管理三个东西：格式状态（怎么显示）、流状态（是否正常）、用户数据（自定义扩展）。

1.1 fmtflags——格式化标志位

// 用函数而非枚举是因为各标志位按位掩码使用
std::ios_base::fmtflags f = std::cout.flags();            // 获取当前 flags
std::cout.setf(std::ios::hex, std::ios::basefield);       // 按分组设置 hex
std::cout.unsetf(std::ios::showbase);                      // 取消单个位
std::cout.flags(std::ios::left);                           // 整值替换 flags

分组名	包含的 flag	含义
basefield	dec / oct / hex	进制显示（互斥，默认 dec）
floatfield	fixed / scientific / hexfloat / (none)	浮点格式（互斥，默认通用格式）
adjustfield	left / right / internal	对齐方式（互斥，默认 right）
独立 flag	boolalpha, showbase, showpoint, showpos, skipws, uppercase, unitbuf	各独立开关（可自由组合）

另有三个非 fmtflags 属性：

方法	含义	默认值
precision(streamsize n)	浮点数有效位数	6
width(streamsize n)	下一个字段最小宽度（一次性）	0
imbue(const locale&)	替换当前 locale	locale::classic()

关键设计：width(n) 是一次性的——输出完一个字段后自动归零。这也是 operator<< 不会让所有后续字段都填充到相同宽度的原因。

1.2 iostate——流健康状态

static constexpr iostate goodbit = 0;     // 一切正常
static constexpr iostate badbit  = 0x1;   // 不可恢复的错误（流已损坏）
static constexpr iostate failbit = 0x2;   // 可恢复的错误（格式错误、读到 EOF）
static constexpr iostate eofbit  = 0x4;   // 到达流末尾

状态检测与处理：

方法	含义
good()	rdstate() == goodbit（一切正常）
fail()	rdstate() & (badbit | failbit)（操作失败）
bad()	rdstate() & badbit（不可恢复）
eof()	rdstate() & eofbit（流尾）
operator bool()	等价于 !fail()，可直接 if (cin)
operator!()	等价于 fail()，可 if (!cin)
clear(iostate state = goodbit)	设置状态（默认重置）
setstate(iostate state)	叠加状态位（不清除已有位）
exceptions(iostate except)	设置哪些状态触发异常

badbit vs failbit：badbit 是"流内部坏了"（如 streambuf 指针为 null），failbit 是"操作没完成"（如读取 int 时遇到了字母）。前者不可恢复，后者可以 clear() 后重试。

1.3 std::ios_base::failure——I/O 异常

class failure : public system_error {  // C++11 起继承 system_error，C++98 只继承 exception
public:
    explicit failure(const string& msg, const error_code& ec = io_errc::stream);
    const error_code& code() const noexcept;
};

配合 exceptions() 使用：

std::ifstream f("data.bin", std::ios::binary);
f.exceptions(std::ios::failbit | std::ios::badbit);  // 出错就抛异常
for (int x; f >> x; ) /* 处理 */
// 若 >> 失败（格式不对或文件读完），自动抛出 ios_base::failure

1.4 iword/pword——用户扩展机制

流内可以挂任意 long / void* 索引，适合给自定义 manipulator 创建 per-stream 状态：

static int idx = std::ios_base::xalloc();  // 分配全局唯一索引
std::cout.iword(idx) = 42;                // 跨 manipulator 传参

每个 ios_base 对象内部分配一个动态扩容的数组，xalloc() 确保索引全局唯一。是线程安全的。

1.5 事件与回调

ios_base 支持注册三个时间点的回调（imbue 时 locale 内容变更、copyfmt 时格式复制、析构前）：

std::ios_base::register_callback(event_callback fn, int index);
// event_callback: void(event ev, ios_base& stream, int index);

三种事件：imbue_event、copyfmt_event、erase_event。主要用于 locale facet 需要在流销毁时做资源回收的场景。

1.6 std::ios_base::Init——全局流对象初始化

一个精巧的 nifty counter 惯用法：

class Init {
public:
    Init();    // 初始化 cin/cout/cerr/clog（若尚未初始化）
    ~Init();   // 刷新 cout/cerr/clog（当最后一个 Init 对象销毁时）
};

每个包含 <iostream> 的翻译单元内部自动生成一个 static ios_base::Init __ioinit; 对象，确保 std::cin / std::cout 在 main() 之前构造完毕，并在 main() 返回后刷新。

1.7 sync_with_stdio——C 与 C++ I/O 的桥梁

static bool sync_with_stdio(bool sync = true);

设置为 true（默认）时，std::cout 和 std::cin 分别与 C 的 stdout / stdin 绑定——输出先写进 C 的 FILE* 缓冲区，保证两次输出不乱序。设置为 false 可大幅提升性能（解绑后 iostream 用独立缓冲），但之后混用 printf 和 cout 会导致输出交错。

关键约束：必须在任何 I/O 操作之前调用，否则行为未定义。

二、basic_ios：流与缓冲的"婚姻介绍所"

2.1 核心方法

方法	含义
rdbuf(streambuf_type*)	设置缓冲区（返回旧指针）
rdbuf() const	获取缓冲区
tie(ostream_type*)	关联输出流（每次输入前先刷新关联流）
tie() const	获取当前关联流
copyfmt(const basic_ios&)	复制格式状态（flags/precision/width/locale）
fill(charT) / fill() const	填充字符
narrow()/widen()	字符编码转换（委托 ctype facet）

2.2 tie()——同步输入输出

这是 cout << "prompt: "; cin >> x; 能正确工作的原因：

// 默认：cin 与 cout 关联（cin.tie(&cout)）
std::cout << "Enter name: ";  // 写进缓存，不刷新
std::cin >> name;             // 输入前，cin 自动调 cout.flush()

内部机制：cin.tie(&cout) 将 cin 关联到 cout，每次从 cin 读数据前，先调用 cout.flush()。解绑：

std::cin.tie(nullptr);          // 解绑，提升性能
std::ios::sync_with_stdio(false); // 同时解绑 C/C++ 缓冲

三、basic_istream / basic_ostream：格式化层的"操盘手"

istream 和 ostream 是用户代码最常接触的类。它们不直接管理缓冲，而是把字节级操作委托给 streambuf，自己只负责两件事：类型转换（格式化）和流状态管理。

3.1 sentry 对象——每次 I/O 的"前哨"

sentry（哨兵）是 iostream 库中 RAII（Resource Acquisition Is Initialization，资源获取即初始化） 惯用法的一个典型应用。每次调用 operator>>、get()、peek()、read() 或 operator<<、put()、write() 等 I/O 函数时，函数入口第一行就是构造一个局部 sentry 对象。

sentry 的设计意图是把"每次 I/O 操作之前都需要做的检查和准备工作"从每个业务函数中抽离出来，统一放到构造函数里执行。它的构造函数按以下顺序执行：

sentry 是"分离关注点"在时间维度上的体现——每个 I/O 函数的业务逻辑只需关心"怎么读写"，而不必反复检查流状态。sentry 析构时（函数 return 或异常抛出）自动完成清理，这就是 RAII 的威力：绝不会出现"忘记 flush"或"忘记恢复 skipws"的问题。

关键行为：

• 构造阶段——"三步检查"：输入 sentry 依次检查 is.good()（流是否可用）、tie()d stream（是否需要刷新关联流）、skipws 标志（是否跳过前导空白）。任何一步失败，sentry 的 operator bool() 都会返回 false，后续的 I/O 操作直接跳过——这就是为什么对流写入了错误状态后，后续所有读写都静默返回而不报错：每个函数都在第一行被 sentry 拦住了。输出 sentry 的检查更简单：只需 os.good() 和 tie()d stream 两步。
• 跳过前导空白：输入 sentry 默认会消耗所有满足 ctype::is(space) 的前导字符（空格、制表符、换行符），这是通过内部循环调用 is.ignore() 实现的。可以用 std::noskipws 操纵符关闭此行为。当执行 std::cin >> n 时，sentry 的构造函数已经把前导空白消耗完毕，后续的 num_get::get() 拿到的第一个字符就是数字本身。
• 析构阶段的自动冲刷：输出 sentry 如果检测到流设置了 unitbuf 标志，析构函数会自动调用 os.flush()。这意味着 std::cout << std::unitbuf; 之后，每一次 operator<< 调用结束都会触发 flush——逐字节写入设备，性能极差。unitbuf 的主要用途是 std::cerr（默认开启），确保错误消息立即输出，不会因程序崩溃而丢失缓冲区中的内容。

3.2 basic_istream 方法全览

无格式化读取（原始字节搬移）

方法	签名	行为
get()	int_type get()	读取一个字符（返回 int_type，可检查是否 traits::eof()）
get(charT&)	istream& get(charT& c)	读取一个字符到 c
get(charT*, streamsize, charT delim)	读取一行到 C 字符串	不跳过前导空白，保留分隔符在流中
getline(charT*, streamsize, charT delim)	读取一行到 C 字符串	不跳过前导空白，丢弃分隔符
read(charT*, streamsize)	原始读取 n 个字节	不识别分隔符，直读
readsome(charT*, streamsize)	读取缓冲区内已有字符（不触发 underflow）	可能返回少于请求的数量
ignore(streamsize n=1, int_type delim=eof)	丢弃最多 n 个字符（遇到 delim 则停止）	常用 cin.ignore(numeric_limits<streamsize>::max(), '\n') 丢弃剩余行
peek()	int_type peek()	偷看下一个字符（不消费，sgetc 后不回退）
unget()	istream& unget()	回退一个字符（sputbackc，最多退一个）
putback(charT)	istream& putback(charT c)	放回一个指定字符（必须是c == sgetc()，否则行为未定义）
gcount()	streamsize gcount()	上次无格式化读取实际读到的字符数
seekg(pos) / seekg(off, dir)	移动读取位置	tellg() 报告当前位移

get vs getline vs read

// input: "abc\n"
char buf[10];
stream.get(buf, 10, '\n');    // "abc": 读到分隔符，不消费分隔符；下一读仍是 '\n'
stream.getline(buf, 10);      // "abc": 读到分隔符，消费分隔符
stream.read(buf, 3);          // "abc": 原始读取，不解析

operator>> 的分派

每个基本类型的 operator>> 最终分派到 locale facet：

operator>>(int&  n)  → num_get<char>::get(buf_iterator, ..., n)
operator>>(string&)  → num_get<char>::get(buf_iterator, ..., str) 或直接读取
operator>>(char*  s) → 手写逻辑（跳过前导空白，读到下一个空白）
operator>>(bool&  b) → num_get<char>::get(...) 或如果 flags 有 boolalpha 则按 "true"/"false" 解析

3.3 basic_ostream 方法全览

方法	签名	行为
put(charT)	ostream& put(charT c)	写一个字符
write(const charT*, streamsize)	原始写入 n 个字符	不格式化，直接 sputn
flush()	ostream& flush()	强刷缓冲区（streambuf::pubsync()）
seekp(pos) / seekp(off, dir)	移动写入位置	tellp() 报告当前位移

operator<< 分派：与 >> 对称，每个类型重载：

operator<<(int n)         → num_put<char>::put(ostreambuf_iterator, ..., n)
operator<<(double d)      → num_put<char>::put(ostreambuf_iterator, ..., d)
operator<<(const void* p) → 格式化为 hex
operator<<(const char* s) → 直到 '\0'，尊重 width
operator<<(bool b)        → boolalpha 时输出 "true"/"false"，否则输出 1/0

3.4 manipulators 全集

manipulators（操纵符）是接受流引用并返回流引用的函数，利用 operator<< 的函数指针重载被调用：

// ostream& operator<<(ostream& (*pf)(ostream&))  — 这就是 manipulator 的入口
cout << hex << 42 << endl;  // hex 和 endl 都是函数指针

标准 manipulators

manipulator	所在头文件	含义
endl	<ostream>	插入 '\n' + flush()
ends	<ostream>	插入 '\0'（用于 C 字符串终结）
flush	<ostream>	调用 os.flush()
ws	<istream>	跳过输入流中的空白字符（is >> ws）
boolalpha / noboolalpha	<ios>	bool 显示为 "true"/"false" 或 1/0
showbase / noshowbase	<ios>	显示/不显示进制前缀（0x/0）
showpoint / noshowpoint	<ios>	浮点总是显示小数点
showpos / noshowpos	<ios>	正数显示 +
skipws / noskipws	<ios>	输入时跳过/不跳过前导空白
uppercase / nouppercase	<ios>	0X 前缀大写 / 科学计数法的 E 大写
unitbuf / nounitbuf	<ios>	每次操作后 flush（cerr 的默认模式）
internal / left / right	<ios>	对齐方式
dec / hex / oct	<ios>	进制选择
fixed / scientific / hexfloat / defaultfloat	<ios>	浮点格式
setprecision(int)	<iomanip>	设置精度
setw(int)	<iomanip>	设置字段宽度
setfill(charT)	<iomanip>	设置填充字符
setbase(int)	<iomanip>	设置进制
setiosflags(fmtflags)	<iomanip>	设置格式标志
resetiosflags(fmtflags)	<iomanip>	清除格式标志
get_money(M&,bool)	<iomanip>	按 locale 格式化货币输入
put_money(const M&,bool)	<iomanip>	按 locale 格式化货币输出
get_time(tm*,const charT*)	<iomanip>	按 locale 格式化时间输入
put_time(const tm*,const charT*)	<iomanip>	按 locale 格式化时间输出
quoted(string&, delim, escape)	<iomanip>	C++14，按 CSV 引号规则读写字符串

endl vs '\n' vs flush：endl = '\n' + flush；每条 endl 就是一次系统调用。高性能路径上只用 '\n'，只在关键点手动 flush。

四、basic_streambuf：缓冲层的"六指针引擎"

4.1 模板参数与类型别名

template<class charT, class traits = char_traits<charT>>
class basic_streambuf {
public:
    using char_type   = charT;
    using int_type    = typename traits::int_type;   // 通常 int（含 EOF = -1）
    using pos_type    = typename traits::pos_type;    // 偏移量
    using off_type    = typename traits::off_type;
    using traits_type = traits;
};

char_traits 默认实现提供字符比较/复制/查找/EOF 检测等功能，char_traits<char> 和 char_traits<wchar_t> 已有标准特化。

4.2 六个 protected 指针——缓冲区状态机的"仪表盘"

basic_streambuf 的核心是一个由六个受保护（protected）成员指针组成的缓冲区状态机。这六个指针分为两组——put area（输出区）和 get area（输入区），各自标记了缓冲区的起始、当前位置和结束边界。子类通过 setp() / setg() 设置它们，通过 pbump() / gbump() 移动它们，从而控制数据的读写流程——不需要调用 malloc 或 memcpy。

六个指针按区域分为两组，命名规则为 {前缀}{用途}ptr()：

区域	指针	含义
put area（输出区）	pbase()	put base：可写区域的起始地址
	pptr()	put pointer：下一个可写位置
	epptr()	end put pointer：可写区域的结束地址
get area（输入区）	eback()	end back：可读区域的起始地址
	gptr()	get pointer：下一个可读位置
	egptr()	end get pointer：可读区域的结束地址

解释这六个指针的相对位置关系：

理解这六个指针，就是理解了 C++ I/O 缓冲的全部秘密。所有 public 方法（sputc、sgetc 等）本质上都是对这六个指针的移动和边界检查，只有到达边界时才调用虚函数 overflow() / underflow() 与设备交互。

4.3 public 接口 vs protected 虚函数

public 方法（快速路径）	protected 虚函数（慢速路径，子类覆写）	触发条件
sgetc() 读当前字符	underflow()	gptr() == egptr()（缓冲区读空）
sbumpc() 读并前进	uflow()（默认调 underflow() + gbump(1)）	同上
sgetn(buf, n) 读 n 个字节	xsgetn(buf, n)	默认用 sbumpc 循环
sputc(c) 写一个字符	overflow(int_type c)	pptr() == epptr()（缓冲区满）
sputn(buf, n) 写 n 个字节	xsputn(buf, n)	默认用 sputc 循环
pubsync() 刷新缓冲区	sync()	用户调用 flush()
pubimbue(loc) 设置 locale	imbue(loc)	流 imbue() 时

这就是 Template Method 模式：基类的 public 方法处理"快速路径"（有缓冲空间时直接操作指针），只在边界情况（满/空）才调用虚函数。子类只需覆写 overflow / underflow / sync / seekoff / seekpos 这几个虚函数，就能完整实现一个缓冲策略。

4.4 streambuf 继承体系——基类定义接口，子类绑定设备

basic_streambuf 本身是一个抽象基类，它定义了六指针操作和虚函数接口，但不绑定任何具体的 I/O 设备。真正"落盘/读文件/写字符串"的逻辑分散在以下三个子类中：

4.5 三种缓冲类对比

缓冲类	存储后端	缓冲模式	关键操作	状态
basic_filebuf	OS 文件描述符	全缓冲（默认，非终端）/ 行缓冲（终端）	open/close/is_open	活跃
basic_stringbuf	std::basic_string<charT>	无中间缓冲（直接读写 string）	str() 获取/设置内容	活跃
basic_strstreambuf	new charT[] 动态分配	无中间缓冲	freeze(bool) / str()	C++98 废弃

4.6 三层分离的完整数据流——一个 int 是怎么变成硬盘上的字节的

将以上各层串联起来，一个完整的"写一个整数到文件"的数据流如下：

• ostream 只负责"格式化"：operator<<(int) 把整数转成字符序列，然后交给 streambuf。
• streambuf 只负责"搬运与缓存"：内部维护 put area / get area 两块缓冲区，overflow() 在缓冲区满时把一整块刷给设备，underflow() 在缓冲区空时从设备拉一整块进来。
• 设备可替换：filebuf 接文件、stringbuf 接内存、strstreambuf（已废弃）接 char[]。换设备不用改任何格式化代码。

这种分离带来的直接好处：缓冲策略（行缓冲/全缓冲/无缓冲）与"写什么"完全无关。这也是为什么 std::cout 默认行缓冲（连到终端时）而 std::ofstream 默认全缓冲——同一个 ostream 接口，背后是不同 streambuf 的缓冲策略。

性能陷阱：std::endl 强制 flush()（调 sync()），把"攒批"的优化彻底废掉。要换行用 '\n'，只在必要时 flush。

五、六大具体流类：组装好的"开箱即用"工具

5.1 文件流三件套

std::ifstream ifs("data.txt");            // 默认 ios::in
std::ofstream ofs("out.txt", ios::app);    // 追加模式
std::fstream  fs("db.dat", ios::in | ios::out | ios::binary);

openmode 标志	含义
in	打开用于读取（ifstream 默认）
out	打开用于写入（ofstream 默认）
app	每次写前 seek 到末尾（追加，与 out 连用）
ate	打开时 seek 到末尾（仅一次）
trunc	清空已有内容（与 out 连用，ofstream 默认）
binary	二进制模式（不转换换行符，不用 text mode 做 \n → \r\n）
ate | app	追加且打开时位于末尾

app vs ate：app 保证每次写入前都 seek 到尾端（即使其他进程修改了文件），ate 只在打开时 seek 一次。

5.2 字符串流三件套

std::istringstream iss("42 3.14 hello");
int n; double d; std::string s;
iss >> n >> d >> s;  // n=42, d=3.14, s="hello"

std::ostringstream oss;
oss << "error: " << errno;      // 构建格式化字符串
std::string msg = oss.str();    // 取出结果（C++11 起支持移动语义，不拷贝）

std::stringstream ss;
ss << "data"; ss >> s;          // 读写同一个 string

stringbuf 的 str() 方法在 C++11 中有两个重载：

• str() const → 返回 string 副本
• str() && → 窃取内部 string（移动语义，不拷贝，stream 变为不可用状态）

std::string s = std::ostringstream{} << "fast: " << compute();  // 直接窃取 string

5.3 废弃的 strstream 家族（不推荐）

废弃类	替代品	为什么废弃
istrstream	istringstream	需要手动管理 char[] 生命周期，freeze 逻辑难用
ostrstream	ostringstream	同上
strstream	stringstream	同上
strstreambuf	stringbuf	freeze(true) 后必须手动 delete[]

// 废弃写法（不要用）：
char buf[256];
std::ostrstream oss(buf, sizeof(buf));  // 写进固定大小 char[]
// 缓冲区满了呢？没有自动扩容，没有任何提示！

六、流迭代器：把 stream 变成平等的 STL 公民

6.1 ostreambuf_iterator —— 输出迭代器

封装 streambuf::sputc() 为输出迭代器接口，让算法直接写入流：

std::ostreambuf_iterator<char> out(std::cout.rdbuf());
std::string s = "hello";
std::copy(s.begin(), s.end(), out);  // 每个字符调用 out.operator=(c) → sputc(c)
// 等价于 std::cout << s

// 判断是否失败
auto it = std::ostreambuf_iterator<char>(file_buf);
// ... 写入 ...
if (it.failed()) { /* 处理失败 */ }

num_put::put 的核心输出接口就是一个 ostreambuf_iterator，所有格式化输出最终通过它进入 streambuf。

6.2 istreambuf_iterator —— 输入迭代器

封装 streambuf::sgetc() 为输入迭代器接口：

std::istreambuf_iterator<char> first(std::cin), last;  // last 是 end-of-stream 哨兵
std::string content(first, last);  // 读取整个 cin 到 string

方法	含义
operator*	返回当前缓存的字符（sgetc() 读第一个字符后缓存）
operator++ / operator++(int)	前进一个字符（调 sbumpc()）
equal(const istreambuf_iterator&)	判断两个迭代器是否等价（都是 end-of-stream 或都不是）

设计精妙处：默认构造的 istreambuf_iterator 即 end-of-stream 哨兵，无需显式维护 EOF 状态。

七、全局流对象：cin/cout/cerr/clog 及其宽字符版

7.1 八个全局流对象

对象	类型	C 对应	缓冲模式	默认关联
std::cin	istream	stdin	—	cout（cin.tie(&cout)）
std::cout	ostream	stdout	行缓冲（连终端）/ 全缓冲（非终端）	无
std::cerr	ostream	stderr	无缓冲（unitbuf 标志始终打开）	cout（cerr.tie(&cout)）
std::clog	ostream	stderr	行缓冲	无
std::wcin	wistream	stdin	—	wcout
std::wcout	wostream	stdout	行缓冲	无
std::wcerr	wostream	stderr	无缓冲	wcout
std::wclog	wostream	stderr	行缓冲	无

7.2 cerr vs clog

std::cerr << "FATAL: disk full\n";  // 立即写进 stderr（无缓冲）
std::clog << "INFO: starting...\n"; // 缓存到行末再写进 stderr（行缓冲）

// cerr 适合崩溃前最后一条消息（必须写入）
// clog 适合普通日志（缓冲后有性能优势）

7.3 并发安全

• 同一流对象的多线程写入不会出现"字符交错"（C++11 起保证），但整个 << 链可能被另一线程插入。
• 用一个 std::mutex 保护 cout 或使用第三方线程安全日志库（spdlog）是更好的做法。

八、C++ I/O 的四大分离维度

上面已逐类拆解了标准库的每一层。现在从"为什么这样设计"高度总结四条核心分离原则。

分离维度	被拆开的两件事	标准库/框架中的体现	类级对应
① 缓冲 vs 设备	"攒一批字节再发" vs "真正落盘/发网卡"	streambuf::overflow/sync	basic_streambuf ↔ basic_filebuf
② 格式化 vs 传输	"把 int 变成字符串" vs "把字符串写出去"	num_put::put → streambuf::sputn	ostream::operator<< ↔ basic_streambuf
③ 同步 vs 异步	"等数据就绪" vs "数据就绪后做什么"	std::future / async / io_context	应用框架层
④ 协议 vs 传输	"TCP 字节怎么切成消息" vs "消息怎么发出去"	应用层 codec 与 socket/read-write 循环	应用框架层

九、格式化与传输的分离：locale facet 体系

9.1 facet 继承结构

ostream 内部把"格式化整数/浮点数/字符串"这件事又进一步委托给 locale facet。一个 locale 由多个 facet 组合而成。

9.2 关键 facet 职责

facet	模板参数	职责	典型使用场景
ctype<charT>	字符类型	字符分类、大小写转换、narrow/widen 转换	isspace(c, loc)
num_put<charT, OutIt>	字符类型 + 输出迭代器	数值 → 字符序列（格式化输出核心）	operator<<(int) 内部调 num_put::put
num_get<charT, InIt>	字符类型 + 输入迭代器	字符序列 → 数值（格式化输入核心）	operator>>(int&) 内部调 num_get::get
collate<charT>	字符类型	locale 感知的字符串排序、比较、哈希	locale 感知的 std::map
codecvt<internT, externT, stateT>	内/外部编码 + 状态	字符编码转换（宽 ↔ 窄）	wstring ↔ string 转换
messages<charT>	字符类型	消息目录查询（catopen/catgets）	i18n 消息翻译
money_put<charT, OutIt>	字符类型 + 输出迭代器	货币格式化输出	put_money manipulator
money_get<charT, InIt>	字符类型 + 输入迭代器	货币格式化输入	get_money manipulator
time_put<charT, OutIt>	字符类型 + 输出迭代器	时间格式化输出	put_time manipulator
time_get<charT, InIt>	字符类型 + 输入迭代器	时间格式化输入	get_time manipulator
numpunct<charT>	字符类型	数字标点符号定义	千位分隔符、小数点字符

9.3 格式化调用链

当执行 std::cout << 42 时，内部的完整调用链：

operator<<(int)
  → num_put<char>::put(...)   // facet：整数→字符序列
    → ctype<char>::widen()    // 十进制数字，不需要宽化
  → ostreambuf_iterator      // 迭代器包装 streambuf
    → streambuf::sputc()     // 快速路径：写进 put area
      → overflow(c)          // 慢速路径：缓冲区满时调

换 locale 只需要替换 num_put facet，同一份 operator<< 代码自动输出德式 3,14 或美式 3.14。

9.4 更进一步的现代分离："先算长度再写"

更高性能的日志库（spdlog / fmtlib）思路一致：

// 传统 iostream：边格式化边调 streambuf，混在一起
std::cout << "value=" << compute() << " status=" << status;

// 现代分离：先在栈上格式化好，最后一次性传输
fmt::memory_buffer buf;
format_to(std::back_inserter(buf), "value={} status={}", compute(), status);
socket.write(buf.data(), buf.size());   // 传输层只看到字节

好处是格式化逻辑可以被独立单元测试、可以被 SIMD 优化、可以不依赖任何 I/O 设备存在。

十、一个反例：把一切搅在一起

// 反模式：格式化、缓冲、设备、业务、协议全挤在一行
void bad_handle(int fd, const User& u) {
    char line[256];
    snprintf(line, sizeof(line),
             "id=%d,name=%s,ts=%ld\n",   // 格式化
             u.id, u.name.c_str(), time(nullptr));
    write(fd, line, strlen(line));        // 传输 + 无缓冲直接发
    // 问题：①无缓冲每次系统调用 ②格式化硬编码 ③fd 含义（协议？日志？）不清
}

对照分离思想，它至少违反了 ①②④：没有缓冲层、格式化与传输耦合、传输与协议语义耦合。

十一、分离思想的工程收益小结

收益	说明
可替换	设备/缓冲/格式化/传输任一环节可独立替换（如 streambuf 换 stringbuf）
可测试	格式化、codec、业务 handler 都能脱离真实 I/O 设备单测
可优化	缓冲策略、SIMD 格式化、零拷贝传输各自独立演进
可并发	同步/异步分离后，单线程事件循环能服务海量连接
可复用	codec 与 transport 解耦后，同一套逻辑跨传输介质复用

延伸阅读：标准库 iostream 内部逐方法详解见 read-write-process.md（系统调用层视角）；ELF 符号表与 _IO_FILE 的关系见 symbol-table.md；高并发网络框架的异步模型见 concepts/network/ 下的事件循环文档；零拷贝传输见 concepts/network/zero-copy.md。

十二、一句话总结

C++ I/O 设计的核心智慧是"分离"：ios_base 管格式 — basic_ios 管连接 — istream/ostream 管类型转换 — streambuf 管字节缓冲 — filebuf/stringbuf 管设备交互，每一层只做一件事。把字节搬运与数据含义、把等待就绪与处理数据、把格式化与传输、把协议与传输逐层解耦——耦合越少，可测试、可优化、可并发的空间就越大。