如何在MSVC VS2017预运行时检测从NULL构造std::string的错误？

首先咱们先理清问题的根源：
当你调用test(NULL)时，NULL在C里通常是个宏，要么定义为整数0，要么是(void*)0。如果是后者，它会被隐式转换成const char*空指针——而std::string的构造函数要求传入的const char*必须指向有效的C风格字符串，空指针直接会触发运行时异常。至于nullptr，标准C里它是std::nullptr_t类型，std::string并没有对应的构造函数，理论上应该触发编译错误，但VS2017的MSVC可能因为兼容性宽松模式，允许了隐式转换，所以没给你警告或错误。

回到你的核心需求：在预运行阶段（编译期）捕获这类问题，以下是几种适合VS2017的方案：

1. 启用MSVC的严格编译选项 #

这是最有效的基础手段：

• 开启/permissive-：禁用MSVC的宽松兼容模式，强制遵循C++标准行为。开启后，传递nullptr给std::string构造函数会直接触发编译错误，因为标准不允许std::nullptr_t隐式转const char*。
• 提升警告等级到/W4：对于NULL（整数0）的情况，这个选项会警告你"整数到指针的隐式转换"，或者当0被当作size_t传递给std::string(size_t, char)构造函数时的隐式类型转换问题。
• 加上/WX：把所有警告升级为错误，强制你在编译期就修复这类问题，不会留到运行时。

2. 利用VS2017的静态分析工具 #

VS自带的静态分析功能能识别这类潜在的危险操作：
通过菜单栏的分析 -> 运行代码分析，工具会扫描代码中传递空指针给std::string构造函数的场景，给出明确的警告提示，甚至能定位到具体代码行。

3. 你自定义的删除构造函数（补充方案） #

你添加的这两行代码：

basic_string(int) = delete;
basic_string(::std::nullptr_t) = delete;

确实能直接捕获传递NULL（整数0）或nullptr的场景，但它的局限性是只能覆盖直接调用的情况——如果空指针是通过变量、函数返回值间接传递的，可能无法检测到。不过在无法修改编译选项的场景下，这是个简单有效的补充，而且不会影响正常代码（毕竟标准库也没有basic_string(int)构造函数）。

4. 养成用nullptr代替NULL的习惯 #

nullptr的类型是明确的std::nullptr_t，不会像NULL那样有整数/空指针的歧义。配合/permissive-选项，编译器能更严格地检查它的使用，从根源上减少这类隐式转换问题。

总结 #

最推荐的组合是/permissive- + /W4 + /WX编译选项，搭配VS的静态分析工具，能在编译期最大程度捕获这类错误。你自定义删除构造函数的方法可以作为补充，覆盖一些编译器可能漏掉的边缘场景。

内容的提问来源于stack exchange，提问作者darune