__builtin_expect 不会改变程序行为，只在-O2及以上、GCC/Clang下有效；它对分支高度偏斜（>95%或
直接说结论：__builtin_expect 不会改变程序行为，只在 -O2 及以上、GCC/Clang 下有效；它对分支高度偏斜（>95% 或
什么时候该用 __builtin_expect？
不是所有 if 都值得加提示。真正该干预的场景非常有限：
- 指针判空（如
if (ptr != nullptr)），且已知 99%+ 情况下非空 - 系统调用返回错误码（如
if (ret == -1)），且错误是罕见事件（ENOMEM、ENOSPC） - 循环内固定边界检查（如
if (i ），且 <code>i几乎总在合法范围内 - 内核或高频服务中被 perf 确认为
branch-misses显著高于 5% 的热点分支
别在调试代码、低频路径、或概率接近 50% 的分支上硬套 —— 编译器自己猜得比你准。
likely 和 unlikely 宏怎么写才安全？
直接调用 __builtin_expect(x, 1) 容易出错：参数必须是编译期常量，且表达式不能带副作用（比如 __builtin_expect(i++, 1) 会导致 i 被算两次）。宏封装是唯一靠谱做法：
#ifdef __GNUC__ #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) #else #define likely(x) (x) #define unlikely(x) (x) #endif
关键点：
- 双叹号
!!(x)强制转成 0/1，避免传入非布尔值（如指针地址本身）导致提示失效 - 只用
__GNUC__判断，不用__clang__单独判断 —— Clang 兼容 GCC 内置函数，但宏定义不一致可能引发隐晦问题 - 宏必须放在头文件里统一包含，禁止在 .cpp 里重复定义
加了提示却没提速？先查这三件事
常见“加了等于没加”的原因：
- 没开
-O2或更高 ——__builtin_expect在-O0或-O1下完全被忽略 - 目标分支实际概率并不偏斜（比如日志开关、配置项检查），编译器静态分析后直接放弃提示
- 函数未内联，而提示只作用于当前函数层级；若分支在被调函数里，外层加
likely没用
验证是否生效最直接的方法：用 objdump -d 看汇编，高概率路径应是连续指令流，低概率路径应跳转到函数末尾附近；再用 perf stat -e branches,branch-misses ./a.out 对比前后分支失误率。
为什么不用 if constexpr 或其他替代方案？
if constexpr 是编译期求值，彻底删掉冷路径代码，和 __builtin_expect 完全不同维度 —— 后者保留全部逻辑，只调换指令布局。两者不互斥，但适用场景泾渭分明：
- 分支条件在编译期可知（如模板参数、
constexpr变量）→ 用if constexpr - 分支条件运行时才确定，但历史数据/业务逻辑表明概率极偏斜 → 用
likely/unlikely - 想消除分支本身（比如用位运算替代 if）→ 走 branchless 编程，和
__builtin_expect是竞争关系，不是补充
最容易被忽略的一点：现代 CPU 的动态分支预测器已经很强，__builtin_expect 的收益正逐年收窄；它现在主要价值不是“提升绝对性能”，而是“让性能更稳定”—— 抑制因分支抖动导致的延迟毛刺，这对实时系统、高频交易等场景才是关键。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
