Item 53：留意 compiler warnings

从一个能编译却分派错误的函数开始

class Base {
public:
    virtual ~Base() = default;
    virtual void render() const;
};
 
class Derived : public Base {
public:
    virtual void render(); // missing const; does not override
};

代码可能合法编译，但 Derived::render 与 Base::render() const 是不同 signatures。derived 同名 declaration 还隐藏 base name。

Item 53 的原则是 Pay attention to compiler warnings（留意编译器警告）。

Derived object;
Base& view = object;
view.render(); // calls Base::render, not Derived::render

warning 不是风格意见，它揭示 runtime behavior 与作者意图不一致。

先预测：直接通过 Derived object 调用和通过 Base reference 调用分别选择哪个 function，再验证 warning 和输出。

override 把 warning 升为错误

class Derived : public Base {
public:
    void render() const override;
};

warning 能发现历史代码的问题，语言特性则能防止问题回归。修复 warning 时应寻找更强契约：override、explicit、[[nodiscard]]、narrow types 或 static assertion。

warning level 是项目配置的一部分

GCC/Clang: -Wall -Wextra -Wpedantic -Wconversion
MSVC:      /W4 /permissive-

选项需按 codebase 和目标平台策划，不是机械复制最大集合。过多无行动价值的 warning 会让团队忽略真正信号。

debug/release、local/CI 应共享核心 profile，避免本地干净而发布配置产生大量未处理诊断。

零新增比一次清零更可执行

旧项目可能已有数千 warnings，立即 -Werror 会阻断所有工作。可先生成 baseline，要求每个 change 不增加 warning，并逐模块偿还。

baseline 必须包含 diagnostic id、file、line fingerprint 和 compiler version；只记录总数会被一增一减掩盖。

每个 warning 都先分类再处理

1. 真实缺陷：未初始化、符号转换、隐藏 virtual、悬空引用。
2. portability：extension、size narrowing、ABI、不同 evaluation assumptions。
3. 意图不明：unused result、fallthrough、implicit conversion。
4. 可证伪报：compiler 无法看穿外部 invariant，但代码有独立证明。

不要为了消除 message 添加无意义 cast、空初始化或注释；那会把 warning 隐藏而不修复 contract。

suppression 必须窄且可追踪

合理抑制应记录：为什么是 false positive、哪条 test/static proof 支持、owner、compiler/version、何时移除。

#if defined(__clang__)
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wspecific-warning"
// one audited third-party boundary
#pragma clang diagnostic pop
#endif

全项目 -Wno-* 会让未来真正缺陷也失声；第三方 headers 应通过 system-header boundary 或独立 target 管理。

warnings 依赖 compiler 和版本

同一 source 在 GCC、Clang、MSVC 上得到不同 diagnostics。一个 compiler 沉默不代表代码正确。

different compilers 是互补静态分析器：某个擅长 lifetime，另一个更严格检查 extension 或 overload ambiguity。

standard library 也会改变诊断表面

libstdc++、libc++、MSVC STL 的 implementation details、annotations 和 deprecated declarations 不同。只在一种 library 构建可能隐藏非标准依赖。

矩阵至少覆盖正式支持的平台，不追求所有可能组合。unsupported job 可定期运行而非每次 PR 阻塞。

-Werror 需要边界

first-party CI 用 warnings-as-errors 能阻止 baseline 增长，但 compiler 升级会引入新 warnings；第三方 headers 和 generated code 不应未经整理直接套同一政策。

升级流程应先在 canary job 收集新增 diagnostics，分类修复或窄抑制，再更新 required toolchain，不能永久冻结 compiler 逃避 warnings。

warning 与 sanitizer/静态分析互补

compiler warning 主要利用局部语法和类型信息。ASan/UBSan/TSan、clang-tidy、专用 analyzer 覆盖运行路径、跨函数 dataflow 和并发。

一个 warning-free build 不是正确性证明；它只是必要质量信号之一。

修复要补行为证据

hidden virtual 修复后不只看 warning 消失，还应测试：

std::unique_ptr<Base> value = std::make_unique<Derived>();
value->render(); // expected Derived behavior

unused return warning 可能对应错误未处理，应测试失败路径；sign conversion warning 对应边界值，应做最小/最大/负数案例。

一套 warning 治理流程

1. 固定 compiler versions、language mode 和 curated profile。
2. 首次扫描建立 diagnostic-level baseline。
3. PR 阻止新增 warning，触碰模块时清理附近存量。
4. 每条 warning 修根因并补 contract/test；只有证据充分才窄抑制。
5. GCC/Clang/MSVC 中正式支持组合进入 required matrix。
6. compiler 升级先 canary，清理新增后提升为 required。

先预测不同 compilers 对隐藏 virtual、narrow conversion 和 non-standard extension 的输出，再以完整 diagnostic id 对照矩阵。

小结

• compiler warnings 常指向真实语义、可移植性或维护风险，不能当背景噪声
• hidden virtual 示例中缺失 const 使 derived 未 override，override 能把意图变成 hard contract
• warning level 应形成 curated project profile，local/CI/release 保持一致
• legacy code 用 diagnostic baseline 和 zero-new-warning gate 渐进清理
• suppression 必须最小、可证明、可追踪，不能全局关闭方便了事
• different compilers、libraries 和 modes 提供互补 portability 证据，但 warning-free 仍需测试和 sanitizer