如何避免std::istream在标准输入与命名管道上的peek阻塞？

你遇到的这个问题本质上是标准输入默认处于阻塞模式导致的——当没有数据可用时，peek()会一直等待直到有输入到来，自然永远走不到else分支。C++标准库本身并没有提供跨平台的非阻塞输入检查方案，不过我们可以借助操作系统的API来实现这个需求，下面分平台给出具体解决思路：

Linux/Unix 平台方案 #

方法1：临时修改文件描述符为非阻塞模式 #

我们可以通过fcntl()系统调用，把std::cin对应的文件描述符（通常是0）临时设置为非阻塞模式，做完检查后再恢复原状态，避免影响后续的正常阻塞读取。示例代码如下：

#include <iostream>
#include <fcntl.h>
#include <unistd.h>

bool has_pending_data(std::istream& s) {
    // 获取std::cin对应的文件描述符
    int fd = s.rdbuf()->fd();
    if (fd == -1) return false;

    // 保存原有的文件状态标志
    int old_flags = fcntl(fd, F_GETFL);
    if (old_flags == -1) return false;

    // 设置为非阻塞模式
    if (fcntl(fd, F_SETFL, old_flags | O_NONBLOCK) == -1) {
        // 恢复原状态后返回
        fcntl(fd, F_SETFL, old_flags);
        return false;
    }

    // 尝试peek，此时不会阻塞
    bool has_data = s.peek() >= 0;

    // 恢复原有的阻塞模式
    fcntl(fd, F_SETFL, old_flags);

    return has_data;
}

方法2：用select()检查是否可读 #

select()可以监听文件描述符的可读状态，在指定超时时间内判断是否有数据到来，这种方式不需要修改文件的阻塞模式：

#include <iostream>
#include <sys/select.h>
#include <unistd.h>

bool has_pending_data(std::istream& s) {
    int fd = s.rdbuf()->fd();
    if (fd == -1) return false;

    fd_set read_fds;
    FD_ZERO(&read_fds);
    FD_SET(fd, &read_fds);

    struct timeval timeout = {0, 0}; // 0秒超时，立即返回
    int result = select(fd + 1, &read_fds, nullptr, nullptr, &timeout);

    // result > 0表示有可读数据，==0表示超时无数据，<0表示出错
    return result > 0;
}

Windows 平台方案 #

Windows下需要用到控制台或管道相关的API，比如对于标准输入控制台，可以用GetNumberOfConsoleInputEvents()；如果是命名管道，可以用PeekNamedPipe()。下面是针对控制台输入的示例：

#include <iostream>
#include <windows.h>

bool has_pending_data(std::istream& s) {
    // 只针对控制台输入的情况
    HANDLE hStdin = GetStdHandle(STD_INPUT_HANDLE);
    if (hStdin == INVALID_HANDLE_VALUE) return false;

    DWORD num_events;
    if (!GetNumberOfConsoleInputEvents(hStdin, &num_events)) {
        return false;
    }

    // 有输入事件存在，说明有待处理数据
    return num_events > 0;
}

注意事项 #

• 这些方案都是平台特定的，因为C++标准没有统一的非阻塞I/O接口，所以如果你需要跨平台支持，需要通过预编译指令区分不同操作系统的代码。
• 如果你后续仍然需要正常的阻塞读取，一定要记得恢复文件描述符的原状态（比如Linux下的fcntl方法），否则后续的输入操作都会变成非阻塞模式，可能导致意外行为。

内容的提问来源于stack exchange，提问作者bartop