C++如何获取控制台的当前列数和行数-C++-PHP中文网

windows下用getconsolescreenbufferinfo获取行列数最可靠，需用srwindow计算宽高（right-left+1为列数，bottom-top+1为行数），而非dwsize；须先获取有效句柄并检查返回值，重定向时应fallback默认值。

c++如何获取控制台的当前列数和行数

Windows下用`GetConsoleScreenBufferInfo`获取行列数

在Windows平台，控制台尺寸不能靠std::cout或std::cin推断，必须调用WinAPI。核心是GetConsoleScreenBufferInfo，它需要一个控制台句柄和CONSOLE_SCREEN_BUFFER_INFO结构体。

常见错误是直接传INVALID_HANDLE_VALUE或没检查返回值——这个函数失败时返回0，不设errno，得用GetLastError()查原因。

必须先用GetStdHandle(STD_OUTPUT_HANDLE)或STD_INPUT_HANDLE获取有效句柄（二者通常指向同一缓冲区）
srWindow.Right - srWindow.Left + 1才是当前窗口宽度（列数），不是dwSize.X（那是缓冲区总宽）
行数同理：用srWindow.Bottom - srWindow.Top + 1，而非dwSize.Y
如果程序重定向了输出（比如myapp.exe > out.txt），GetStdHandle会返回无效句柄，需提前判断

// 示例：安全获取当前窗口行列
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
if (hOut == INVALID_HANDLE_VALUE) {
    // 不在控制台环境，按默认值处理
    return {80, 25};
}
CONSOLE_SCREEN_BUFFER_INFO csbi;
if (!GetConsoleScreenBufferInfo(hOut, &csbi)) {
    return {80, 25}; // API失败，fallback
}
int cols = csbi.srWindow.Right - csbi.srWindow.Left + 1;
int rows = csbi.srWindow.Bottom - csbi.srWindow.Top + 1;

Linux/macOS用`ioctl`配`TIOCGWINSZ`

类Unix系统没有统一API，标准做法是向STDOUT_FILENO（或STDIN_FILENO）发ioctl系统调用，参数为TIOCGWINSZ，读取winsize结构体。

容易踩的坑是忽略信号中断（EINTR）和重定向场景：当输出被管道或文件重定向时，ioctl会失败并设errno = ENOTTY，此时不能硬报错，得fallback。

必须包含<sys></sys>和<termios.h></termios.h>，否则编译报错
winsize.ws_col和winsize.ws_row就是当前列数、行数，无需计算
某些精简环境（如容器内无tty）可能始终返回0，建议设置合理默认值（如{80, 24}）
别用stdin代替STDOUT_FILENO——虽然多数情况等价，但POSIX不保证

// 示例：跨终端兼容读取
struct winsize w;
if (ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) == 0 && w.ws_col > 0 && w.ws_row > 0) {
    return {w.ws_col, w.ws_row};
} else {
    return {80, 24}; // fallback
}

跨平台封装要注意`isatty`判据

写一次代码跑多平台时，不能只靠预处理器宏分条件编译，还得运行时确认是否真有控制台。关键函数是isatty(STDOUT_FILENO)（POSIX）或_isatty(_fileno(stdout))（MSVC）。

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

很多人忽略这点，导致程序在./app | less或CI流水线里崩溃——因为管道两端都不是tty，但ioctl或GetConsoleScreenBufferInfo仍被调用。

Windows下_isatty需链接libcmt.lib（静态）或msvcrt.lib（动态），否则链接失败
Linux/macOS下isatty在<unistd.h></unistd.h>里，但某些嵌入式libc可能不提供
即使isatty返回true，也不能保证ioctl或API一定成功，仍要加错误处理分支

为什么不能用`GetLargestConsoleWindowSize`或`ws.ws_xpixel`

这两个是高频误解点：GetLargestConsoleWindowSize返回的是“理论上能设置的最大窗口尺寸”，不是当前值；winsize.ws_xpixel/ws_ypixel在绝大多数终端里恒为0，Linux内核从不填充它们，glibc也明确文档标注“保留未用”。

还有人试图解析$COLUMNS/$LINES环境变量——这不可靠：zsh/bash可能设置，但dash、fish不一定，且用户可随意篡改，与实际终端尺寸脱节。

Windows上GetConsoleScreenBufferInfo的dwMaximumWindowSize字段才是最大值，别和srWindow混淆
不要依赖ws_xpixel做响应式布局，它在xterm、gnome-terminal、iTerm2里全为0
环境变量只能作为fallback的fallback，优先级应低于API/系统调用

真正难的是处理重定向、伪终端（如VS Code集成终端）、远程SSH会话里的尺寸变化事件——这些场景下，行列数可能中途变更，但C++标准库不提供通知机制，得自己监听SIGWINCH（Unix）或轮询（Windows），这已经超出“获取当前值”的范畴了。