Sublime深度定制编译系统参数_一键执行C++算法竞赛测试用例-sublime-PHP中文网

sublime构建系统传入自定义测试用例文件需用shell_cmd模式配合重定向：linux/macos用

编译系统里怎么传入自定义测试用例文件？

Sublime 的 sublime-build 文件默认不支持动态读取外部文件作为输入，直接写 stdin 重定向会失败——因为 Sublime 的构建系统不执行 shell 解析， 这类语法会被当作字面参数传给可执行程序，导致报错 <code>No such file or directory 或程序直接卡住。

可行方案是改用 shell_cmd 模式，并显式调用 bash（或 sh）来解析重定向：
{
    "shell_cmd": "g++ -std=c++17 -o ${file_base_name} ${file} && ./${file_base_name} &1",
    "working_dir": "${file_path}",
    "selector": "source.c++, source.cpp"
}
${file_base_name}.in 是约定的输入文件名，比如 main.cpp 对应 main.in

必须用 shell_cmd，不能用 cmd；Windows 用户需改用 cmd /c 并用 type 模拟重定向（见下一条）

2>&1 把 stderr 合并到 stdout，确保错误信息也能在 Sublime 输出面板看到

Windows 下重定向输入为什么总失败？

Windows 命令行不支持 直接重定向到可执行文件（尤其当 exe 在当前目录时），常见错误是 <code>The system cannot find the file specified，其实是 cmd 找不到输入文件路径，或重定向被忽略。

绕过方法：用 cmd /c 调起命令，并用 type 管道传递内容：
{
    "shell_cmd": "cmd /c "g++ -std=c++17 -o ${file_base_name}.exe ${file} && type ${file_base_name}.in | ${file_base_name}.exe 2>&1"",
    "working_dir": "${file_path}",
    "selector": "source.c++, source.cpp"
}
双引号必须成对且转义，否则 Sublime 解析失败

type 要求 .in 文件存在且编码为 ANSI/GBK（UTF-8 with BOM 可能出乱码）

如果测试用例含中文或特殊字符，建议统一保存为 UTF-8 无 BOM，并在 C++ 代码里用 ios_base::sync_with_stdio(false) 避免缓冲干扰

如何让一次构建同时跑多个测试用例？

原生构建系统不支持循环或批量执行，但可以用 Python 脚本桥接——写一个 run_tests.py，放在项目根目录，然后在 .sublime-build 中调它：

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

下载
{
    "shell_cmd": "python run_tests.py ${file_path} ${file_base_name}",
    "working_dir": "${file_path}",
    "selector": "source.c++, source.cpp"
}
run_tests.py 核心逻辑只需几行：
import sys, os, subprocess
folder, name = sys.argv[1], sys.argv[2]
for f in sorted(os.listdir(folder)):
    if f.startswith(name + ".") and f.endswith(".in"):
        case = f[:-3]
        print(f"
=== {case} ===")
        subprocess.run([f"./{name}", "
脚本会自动匹配 main.001.in、main.002.in 等命名格式

注意 Windows 上要改成 subprocess.run(f"type {case}.in | .\{name}.exe", shell=True)

别忘了给脚本加执行权限（macOS/Linux），或确保系统已注册 python 命令

输出结果太长，怎么快速定位 WA 或 RE？

Sublime 构建面板默认只显示最后 100 行，而算法题常有大输出或崩溃堆栈被截断。关键不是调高日志上限（不可控），而是提前过滤和标记异常信号。

推荐在 shell_cmd 末尾加判断逻辑：
... && ./${file_base_name} &1 | grep -E '^(Segmentation|Aborted|WA|TLE|Runtime)' || true
grep 不会阻塞输出，只高亮关键词；没匹配时返回 0（靠 || true 保证构建不标红）

更稳的做法是用 Python 脚本做 diff：读 .in 和预期 .out，比对实际输出，直接打印差异行

别依赖 return code 判断 AC/WA——很多 OJ 风格程序无论对错都 return 0，得看 stdout 内容

真正麻烦的是调试时不知道哪组用例崩了，所以文件命名和日志前缀（如 === test01 ===）比任何 fancy 插件都管用。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！