C++标准库替代方案：GSL（Guidelines Support Library）使用指南【微软推荐】_技术教程

GSL是补足标准库安全缺口的轻量工具集，提供gsl::at()越界检查、gsl::narrow()截断防护、gsl::not_null空指针编译期拦截，但需启用C++ Core Guidelines检查器才能发挥预警作用。

GSL 不是“替代”标准库，而是帮你更安全地用好标准库的轻量工具集——它不提供新容器或算法，只补足边界检查、空指针防护、类型转换等关键安全缺口。

什么时候该用 `gsl::at()` 而不是 `operator[]`

当你在循环里用非常量索引访问 std::vector、std::array 或原生数组时，operator[] 完全不检查越界，而编译器（尤其开启 MSVC 的 C++ Core Guidelines 检查）会直接报 C26446 警告。

✅ 安全写法：gsl::at(vec, i) 或 vec.at(i) —— 两者都抛 std::out_of_range，但 gsl::at 对原生数组也有效
❌ 危险写法：vec[i]（i 是变量）、arr[i]（arr 是 int arr[10]）
⚠️ 注意：std::string_view 的 operator[] 同样不安全，也需改用 gsl::at(sv, i)

#include 
#include 
std::vector v = {1, 2, 3};
int x = gsl::at(v, 5); // 运行时报 std::out_of_range，而非未定义行为

如何避免 `static_cast` 引发的静默截断？用 `gsl::narrow` 和 `gsl::nar row_cast`

比如把 uint32_t 拆成三个 uint8_t 像素值时，static_cast 不报错，但高位非零会导致数据丢失——C26472 就是为此而设。

✅ gsl::narrow(v >> 16)：严格检查，越界则抛 gsl::narrowing_error
✅ gsl::narrow_cast(v & 0xFF)：明确承认可能丢数据，且你已确认安全
❌ 不要用 static_cast(v) 替代，尤其在处理外部输入或计算中间值时

auto rgb_from_24bit(uint32_t v) noexcept {
    return std::array{
        gsl::narrow(v >> 16),   // 安全：高位必须为 0
        gsl::narrow_cast((v >> 8) & 0xFF), // 显式接受低位截断
        gsl::narrow_cast(v & 0xFF)
    };
}

为什么 `gsl::not_null` 比 “加个注释说不能传 nullptr” 强得多

它把空指针检查从运行时提前到编译期，且对裸指针、智能指针、自定义句柄都统一支持。一旦传入 nullptr，连编译都过不去。

✅ 函数参数强制非空：void draw(gsl::not_null s)，调用 draw(nullptr) 直接报错
✅ 支持智能指针：gsl::not_null<:shared_ptr>>，避免 make_shared() 返回空的误用
⚠️ 注意：gsl::not_null 是零开销抽象（无成员变量），但构造时若传入空指针，行为是未定义（所以务必靠编译器拦截）

void process(gsl::not_null p) {
    *p = 42; // 编译器保证 p != nullptr，可放心解引用
}
int x = 0;
process(&x);     // ✅ OK
// process(nullptr); // ❌ 编译失败

真正容易被忽略的是：GSL 的安全机制只在你「主动启用」时才起作用——MSVC 需开启 C++ Core Guidelines 规则集，Clang/GCC 则依赖静态分析工具（如 clang-tidy 的 cppcoreguidelines-* 规则）。不配置检查器，gsl::at 和 gsl::narrow 依然能用，但警告不会自动出现，等于关掉了最重要的哨兵。