C++中的std::not_null指针有什么建议用法？(提高代码的安全性)

std::not_null 是 GSL 提供的非空指针契约工具，用于函数参数、返回值和成员变量中明确要求非空语义的场景，不适用于可能为空的情况。

std::not_null 不是标准 C++ 库的一部分，它来自 GSL（Guidelines Support Library），由 Microsoft 主导维护，用于表达“该指针绝不应为 nullptr”的契约。它本身不提供运行时检查，也不改变底层指针行为，而是靠编译期约束和静态分析辅助提升安全性。

什么时候该用 not_null 而不是裸指针或 std::shared_ptr？

核心场景是：函数参数、返回值、成员变量中，你**明确要求调用方/使用者必须传入有效地址，且空值在逻辑上无意义**。

• 函数形参声明为 not_null，能阻止传入字面量 nullptr 或明显未检查的指针（如 f(not_null(p)) 若 p 是 nullptr，某些编译器+GSL 实现会在构造时触发断言）
• 类成员若代表“始终拥有一个有效对象”，比如 class Window { not_null hwnd_; };，比 HWND hwnd_; 更具语义强度
• 避免误用 std::shared_ptr：当不需要所有权管理、仅需非空引用时，not_null 开销更小、意图更清晰
• 不适用于可能为空的场景（如可选资源、缓存未命中），此时应继续用 T*、std::optional 或 std::unique_ptr

常见误用与坑点

not_null 的安全收益高度依赖使用方式——它不自动做空检查，也不拦截运行时解引用空指针。

• 从原始指针构造时未校验：not_null(p) 若 p 已是 nullptr，多数 GSL 实现在 debug 模式下会 assert，但 release 模式下可能静默通过（取决于实现和宏定义，如 GSL_UNENFORCED_ON_CONTRACT_VIOLATION）
• 忽略隐式转换限制：不能直接赋值 nullptr，但可通过 static_cast 绕过，失去防护意义
• 与智能指针混用易混淆：not_null<:shared_ptr>> 合法但罕见；通常应选 not_null + 由外部确保生命周期，或直接用 std::shared_ptr 表达所有权
• 模板推导陷阱：写 auto p = not_null{ptr} 时，若 ptr 类型不明确（如函数重载返回不同指针类型），可能推导失败

如何正确初始化和传递 not_null

关键原则：把空值检查提前到构造点，并让调用链上游承担非空保证责任。

磁力开创

快手推出的一站式AI视频生产平台

下载

立即学习“C++免费学习笔记（深入）”；

void process_data(not_null ptr) {
    // 此处 ptr.get() 必不为 nullptr（假设构造时已校验）
    *ptr += 1;
}
int x = 42;
process_data(not_null{&x}); // ✅ 明确、安全
// ❌ 危险：p 可能为 nullptr，构造时才暴露问题
int p = get_raw_ptr();
process_data(not_null>{p}); // debug 下 assert，release 下未定义行为风险仍在

• 优先在可信上下文中构造：not_null 对象应在确定非空后立即创建，而非长期持有裸指针再转
• 函数返回 not_null 时，必须确保所有代码路径都返回有效指针（否则需抛异常或终止，不能返回 nullptr）
• 配合 clang-tidy 或 CppCoreGuidelines 检查器，可捕获 not_null 构造前缺少空检查的模式