C++ nullptr和NULL区别 C++ 空指针类型安全问题解析【类型】

NULLptr 不能赋值给整数变量是因为其类型为 std::nullptr_t，仅可隐式转换为指针类型；NULL 是整型宏（如 0 或 0L），故可赋值给整数变量，但易引发类型混淆。

为什么 nullptr 不能赋值给整数变量而 NULL 可以

NULL 在多数标准库实现中是 0 或 0L 的宏定义，本质是整型常量；nullptr 是 c++11 引入的字面量，类型为 std::nullptr_t，只能隐式转换为任意指针类型，不参与整型上下文。

常见错误现象：int x = NULL; 合法但危险，int x = nullptr; 编译失败——这正是设计目的：暴露类型混淆。

• 使用场景：函数重载时，void f(int) 和 void f(char*) 同时存在，f(NULL) 会调用 f(int)（因 NULL 是整数），而 f(nullptr) 明确调用指针版本
• 参数差异：nullptr 是右值，std::nullptr_t 类型不可取地址；NULL 是宏，预处理阶段替换，无类型信息
• 兼容性影响：C++98/03 代码若依赖 NULL 作整数用，升级到 C++11 后改用 nullptr 会触发编译错误，需人工审查逻辑

nullptr 在模板推导中为何更安全

模板参数类型推导对 nullptr 能准确得到 std::nullptr_t，而 NULL 会被推成 int 或 long，导致后续指针操作失效。

示例：template void foo(T t) { static_assert(std::is_pointer_v, "T must be pointer"); } —— foo(nullptr) 通过，foo(NULL) 编译失败（T 推导为 int）。

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

• 容易踩的坑：泛型容器或智能指针构造函数中传 NULL，可能意外触发整数构造而非指针构造（如 std::unique_ptr p(NULL); 在某些旧实现中可能调用 explicit unique_ptr(pointer)，但语义模糊）
• 性能无差异：两者都是编译期常量，生成的机器码相同，安全性的提升不带来运行时开销

跨平台项目里 NULL 宏定义不一致带来的问题

POSIX 系统头文件常将 NULL 定义为 ((void*)0)，而 windows SDK（尤其旧版）可能定义为 0；C++ 标准只要求 NULL 可隐式转为任意指针类型，不规定具体展开形式。

后果：在函数重载 + 模板 + 头文件包含顺序复杂的项目中，NULL 行为可能因平台或编译器不同而变化，nullptr 则完全标准化、无歧义。

• 实操建议：用 grep -r "define NULL" /usr/include（linux）或检查 windef.h（windows）确认实际定义；但更稳妥的做法是全局搜索并替换 NULL 为 nullptr（注意排除 C 头文件或 C 风格接口）
• 混合语言项目：C++ 代码调用 C 函数时仍可传 nullptr（C++11 起保证与 C 的 NULL 兼容），但 C 代码不能用 nullptr

什么时候还必须用 NULL？

几乎没有。唯一例外是明确需要整数零值的上下文，且不能写 0（比如历史代码风格强制所有“空值”统一用 NULL），但这属于人为约束，非技术必需。

真正需要注意的是：C 头文件（如 ）中声明的函数接受 void* 参数时，传 nullptr 完全合法；但若该函数内部做整数运算（如指针算术误用），问题不在空值表示方式，而在逻辑错误本身。

• 容易被忽略的点：nullptr 不能用于位运算（nullptr & 1 报错），NULL 可以（因是整数）——但这恰恰说明你在不该用空值的地方做了整数操作
• 遗留系统迁移：若代码大量使用 #ifdef __cplusplus 区分 C/C++，且 NULL 在 C 部分被重新定义，需确保 C++ 部分不依赖其整数特性