VC2019中带const char*非类型模板参数的类初始化std::pair基类崩溃乱码

该问题不属于std::pair的设计缺陷，本质是C++规则中非类型模板形参传递、列表初始化匹配构造函数的晦涩特殊特性，叠加VC2019的编译器实现缺陷共同导致。

异常产生的具体逻辑 #

• 代码中模板类C的非类型形参为const char*指针类型，C++标准对这类指针对象作为模板实参的链接属性、传入规则存在多版本迭代带来的差异，不同编译器的兼容实现差别极大。
• 初始化列表中str_int{ V, 0 }的写法，依赖编译器完成两步隐式匹配：首先将V（类型为const char*）匹配到pair<string, int>的构造函数入口，再隐式将const char*转换为std::string完成成员构造。
• main函数中str_int si{str, 0}的写法可以正常运行，是因为str是直接作为全局常量传入的实参，不涉及模板非类型形参的传递逻辑，VC2019对这个场景下的构造匹配逻辑是正常的。
• VC2019在该模板场景下存在实现缺陷：对从模板形参获取的指针值作为pair初始化参数时，没有正确完成构造分支匹配，错误把原始const char*指针值当成已构造完成的std::string对象的内存地址，后续访问该无效内存就会触发程序崩溃、输出乱码的问题。

修正方案生效的原因 #

• 将初始化写法替换为str_int{ string{V}, 0}时，会显式指定第一个成员的构造参数类型，直接绕开pair构造函数的隐式参数推导过程，彻底消除构造分支匹配的歧义，因此程序可以正常运行。
• 部分在线编译器运行正常的现象，来自GCC、Clang等编译器的较新版本已经修正了该场景下的构造函数匹配逻辑，能够正确将const char*参数匹配到std::string的构造路径，没有复现VC2019的实现错误。

在C++11/14标准环境下编译该代码，constexpr修饰的内部链接常量作为指针类型非类型模板实参本身就不符合标准要求，这也是不同编译器环境下行为不一致的重要诱因。

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