showmanyc：C++里那个总被忽略的字符数“天气预报员”

你有没有试过用 std::cout << std::hex << std::showbase << 123;，结果发现输出是 0x7b，但紧接着加个 std::showmanyc——咦？没反应？控制台照旧，调试器也没报错，仿佛它根本不存在。
这不是你的错觉。std::showmanyc 确实是个“静音型”操纵符，不打印、不换行、不改格式，只默默在流缓冲区底层做一件事：预估当前输入缓冲中“可立即读取的字符数”。它不消费字符，也不触发等待，更不像 peek() 那样返回值——它只是问一句：“如果我现在伸手去拿，大概能摸到几个？”

这听上去像玄学，但恰恰是它最实用的地方：避免阻塞式等待，提前感知输入节奏。

showmanyc 属于 <ios> 中的 ios_base::iostate 辅助工具，但它从不单独使用。它的真身是 basic_streambuf::showmanyc()——一个受保护的虚函数，由具体流缓冲类（如 filebuf、stringbuf，甚至某些自定义 streambuf）实现。标准输入流 std::cin 对应的 streambuf（通常是 __stdinbuf<char> 或类似实现）在绝大多数系统上返回 -1。不是 0，不是 1，是 -1。文档写的是“unspecified”，但现实很直白：终端输入不支持预估。

为什么？因为键盘敲击是异步事件，操作系统把输入暂存在行缓冲区，直到回车才批量交给程序。你问“现在有几字节可读”，内核只能摊手：“我刚收到‘h’，但用户还没按回车——算不算？不算？那我得等。” 所以 cin.rdbuf()->showmanyc() 基本恒为 -1。这不是 bug，是设计使然。

但别急着关页面。showmanyc 的价值，藏在它 真正起作用 的场景里。

文件流就是它的主场。

std::ifstream fin("log.txt");
fin.rdbuf()->showmanyc(); // 可能返回正整数

此时它可能返回剩余未读字节数（取决于底层 filebuf 实现与 OS 支持）。Linux 下 filebuf 常通过 stat() 或 lseek() 获取文件大小减去当前偏移，给出近似值；Windows 上类似。注意：它返回的是“缓冲区已加载且未消费的字节数”，不是文件总长度——如果文件很大，而缓冲区只预读了 4KB，那它就只告诉你“眼前这 4KB 里还剩多少没读”。

更关键的是：它不触发磁盘 I/O。比起 fin.seekg(0, std::ios::end); auto size = fin.tellg(); 这种会真实跳转、可能打断流状态的操作，showmanyc 是轻量级探针——适合高频轮询小数据源，比如监听串口日志、管道输入或内存映射文件。

真正让 showmanyc 活起来的，是你自己写的 streambuf。
假设你在做嵌入式日志转发，数据从 UART 缓冲区源源不断进来，存进一个环形队列。你继承 std::streambuf，重写 underflow() 从队列取字节。这时，showmanyc() 就可以直连队列的 available() 方法：

class uart_streambuf : public std::streambuf {
    ring_buffer& buf;
protected:
    int showmanyc() override { return buf.available(); } // 直接返回待读字节数
    int_type underflow() override { /* 从 buf 取一字节 */ }
};

现在，上层代码可以这样非阻塞地判断：

if (uart_stream >> std::ws && uart_stream.rdbuf()->showmanyc() >= 16) {
    char buf[16];
    uart_stream.read(buf, 16); // 知道够读，放心批量取
}

没有 wait()，没有超时，没有 poll() 系统调用——仅靠流接口完成节奏感知。这才是 showmanyc 的本意：给流一个“呼吸感”，让它知道下一口气能吸多深。

有人问：“C++23 有没有替代方案？”
有，但不是取代。std::osyncstream 解决线程安全输出，std::spanstream（C++23）优化内存流，但它们都不回答“此刻缓冲里有多少可用输入”。showmanyc 的不可替代性，正在于它对底层缓冲状态的“零开销窥视”。它不承诺精确，但承诺快速；不保证跨平台一致，但尊重各平台 I/O 模型的差异。

所以，别再把它当彩蛋或废弃接口。下次当你需要在不阻塞的前提下试探输入水位——无论是文件解析的预分配、网络包粘包的启发式拆分，还是硬件通信的流量调控——记得问问 rdbuf()->showmanyc()。它可能只回你一个 -1，也可能回你一个精准的数字。而你知道该信哪一个，也明白为什么。

它不是万能钥匙，但确实是那把常被塞进抽屉深处、却专治某几把锁的薄刃小刀。