为什么一定要开 -Wshadow？

为什么我总是说一定要开 -Wshadow？一段代码教你“变量遮蔽”有多坑！

一个不起眼的警告，救回一个通宵的 bug。

---

先看一段代码，猜猜它哪里炸了？

#include <algorithm>
#include <iostream>
#include <math.h>

const int N = 5e5 + 7;
auto upd = [](auto& x, auto&& y) { x = std::max(x, y); };

int lp[N], rp[N], id[N], maxi[N];

int main() {
  // ... 一堆分块初始化
  auto rebuild = [&](int i) { // 这里的 i 是块编号
    // ... 中间处理
    for(int i = 1; i <= idx; ++i) { // 这里 i 变成了循环变量！
      maxi[i] = std::max(maxi[i], value[i]);
    }
    tim[i] = now;
  };
  // ...
}

这是一道分块数据结构题的核心函数，编译、运行，看似完美，但偶尔答案就是不对。

---

🕵️‍♂️ 到底错在哪？

第68行是：

maxi[i] = std::max(maxi[i], value[i]);

直觉上，这行是想把 当前块 的 maxi 更新为 value 中的最大值。
但请注意：外层函数参数也叫 i（auto rebuild = [&](int i)），而这里又定义了一个循环变量 i！

在 C++ 中，内层作用域的变量会遮蔽（shadow）外层同名的变量。
所以第68行里的 i 是循环变量，取值范围是 1..idx（一个临时编号），并不是外层传入的块编号。
于是，本该更新的 maxi[块号] 变成了 maxi[1]、maxi[2]……这些位置可能根本不代表任何块，或者覆盖了其他块的数据。

---

🔥 没有 -Wshadow，编译器一声不吭

这段代码在大多数编译器默认选项下零警告、零报错，逻辑自洽，完美编译。
你甚至跑了很多样例，只有大数据时偶尔出错——查了半天，怀疑人生。

但只要你加上一句编译选项：

g++ -Wshadow -O2 code.cpp

编译器立刻会给你一巴掌：

warning: declaration of ‘i’ shadows a previous local [-Wshadow]
    for(int i = 1; i <= idx; ++i) {
         ^
note: shadowed declaration is here
    auto rebuild = [&](int i) {
                        ^

一秒定位：哦，原来这儿有个变量名字冲突！
再仔细一看，maxi[i] 的索引根本不是块号，赶紧改成 maxi[outer_i] 或者把循环变量改名——bug 解除。

---

🤔 为什么“变量遮蔽”这么危险？

• 肉眼难辨：两个 i 长得一模一样，读代码时很容易忽略。
• 编译无错：语法完全合法，编译器默认不会报警。
• 影响逻辑：你以为在操作 A，实际在操作 B，数据被悄无声息地篡改。
• 难以复现：这类 bug 常常只在特定输入下触发，调试起来极度耗时。

像这份代码，如果没有 -Wshadow，你可能会怀疑是分块大小不对、离散化出错、并查集写挂了…… 永远不会想到是变量名冲突。

---

✅ 请把 -Wshadow 加入你的“默认编译套餐”

对于 GCC/Clang：-Wshadow
建议在 CMakeLists.txt 或 Makefile 里强制开启，把它和 -Wall -Wextra 绑定。
即使你觉得代码“不可能有阴影”，也请打开——编译器是程序员最忠诚的伙伴，别辜负它。

---

📌 总结：一次阴影，一生教训

变量遮蔽就像办公室里的“同名同事”——你喊一声“小王”，可能三个人回头。
如果不用名字区分（比如 -Wshadow），就会造成混乱，甚至关键时刻找错人。

下次写代码前，请先加上 -Wshadow。
它会保护你免受无数个深夜 debug 的折磨，让你的代码更健壮、更可读。

---

彩蛋：如何彻底避免？

• 给循环变量起个有意义的名字，比如 for(int j = 1; j <= idx; ++j)
• 给函数参数起名时加上前缀，比如 block_id
• 开启 -Wshadow 并把警告当作错误（-Werror=shadow）

你的代码，值得被认真对待。
如果你也曾被变量遮蔽坑过，欢迎留言分享你的“血泪史”👇

---

（完）