c++oding="utf-8" ?>

dev-c++断点失效主因是未生成调试信息、优化级别非零、断点设在空行/注释/预处理行；需勾选generate debugging information、设-o0、打在有效代码行。

断点调试不是“高级功能”，而是你写完 main() 后就该立刻用上的基本动作。它不依赖 IDE 多强大，只取决于你是否在编译时保留了调试信息、是否理解“断点停在哪一行”这个关键细节。

Dev-C++ 里断点打不上？先检查这三件事

很多人按了 F4 或点了行号左侧，红色圆点没出现，或者出现了但运行时不暂停——大概率是以下问题：

• 编译器没生成调试信息：进 Tools → Compiler Options，必须勾选 Generate debugging information
• 优化级别不是 None：哪怕只勾了 -O1，gdb 就可能把变量优化掉、跳过断点行，导致“断点灰色”或“直接跑过”
• 断点打在了无效位置：比如空行、注释行、预处理指令行（#include、#define），这些地方没有对应机器码，点不亮

VSCode 中断点显示为空心圆？别急着重装插件

空心圆（◌）不是 bug，是 VSCode 明确告诉你：“这行代码没被编译进去”。常见原因和解法：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• launch.json 里 program 路径指向了旧的可执行文件，而你刚改了源码但没重新编译——删掉旧 .exe 或 ./a.out，再按 F5
• tasks.json 没配 -g 参数：gcc/clang 编译命令里缺了 -g，生成的二进制就没有调试符号，断点必然失效
• c_cpp_properties.json 的 includePath 错了，导致头文件解析失败，某些内联函数或模板实例化被跳过，断点所在行实际未参与编译

什么时候该用条件断点而不是普通断点？

当你面对一个循环执行 10000 次的 for，只想看第 9999 次时 data[i] 的值，手动按 F8 一千次不现实。这时要靠条件断点：

• Dev-C++ 不支持原生条件断点，得靠临时加 if (i == 9999) __debugbreak(); 配合编译调试版
• VSCode 或 Qt Creator 可右键断点 → Edit Breakpoint → 输入 i == 9999；GDB 命令行用 break main.cpp:42 if i==9999
• 注意：条件表达式里不能用未初始化的变量，也不能调用复杂函数（比如 strlen()），否则断点可能不触发或崩溃

单步执行时“跳进函数”还是“跳过函数”？看这行有没有花括号

新手常困惑 F7（Step Into）和 F8（Step Over）的区别。最直白的判断依据是当前行是否调用了你自己写的、有函数体的函数：

• 如果这行是 printf("hello"); 或 std::cout ，F7 通常不会进入实现（除非你装了 libc++ 源码并配置了符号路径），F8 和 F7 行为几乎一样
• 如果这行是 process_data(arr, len);，且 process_data 是你自己定义的函数（.cpp 文件里有 { ... }），F7 会跳转到函数第一行，F8 则直接执行完该函数再停
• 光标停在 return 上按 F7，会返回上一层调用处；停在 } 上按 F7，行为不确定——有些调试器会跳到调用点下一行，有些会卡住，建议避免在这种位置单步

真正容易被忽略的，是“断点生效的前提从来不是 IDE 图形界面多漂亮，而是你手动生成的可执行文件里有没有 .debug_* 段”。哪怕用记事本写代码、命令行编译，只要加了 -g，就能用 GDB 打断点。图形界面只是帮你点了几下鼠标，背后全是同一套调试信息在起作用。

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