MSVC C++17下overload/std::visit触发栈损坏运行时检查失败#2

核心问题回顾 #

我使用overload模式为std::variant实现访问器，将处理方法定义为lambda，其中最后一个无捕获泛型lambda作为默认处理。在MSVC 2022（v17.7.6）的C17 Debug编译模式下，程序退出时触发「Run-Time Check Failure #2 - 变量'picky_eater'周围的栈已损坏」异常，Release模式运行正常；若给最后一个lambda添加捕获，或切换至C20标准，该异常消失。需确认：

1. 此异常是否说明原代码存在真实问题？
2. C++20是否引入了相关修正？
3. 这是否是MSVC C++17 Debug运行时检查的特殊bug？

1. 异常是否指向代码真实问题？ #

这个栈损坏异常大概率不是你的代码本身有逻辑错误，而是MSVC在C17标准下对无捕获泛型lambda的处理存在编译/运行时检查的实现瑕疵。你的代码写法在C标准层面是合规的：overload模式组合lambda作为variant访问器是常规用法，无捕获泛型lambda作为默认分支也符合C++17对lambda和variant访问器的要求。Debug模式下的栈损坏提示，通常是编译器插入的栈探测代码检测到内存越界，但这里的越界更可能是编译器生成的辅助代码（比如lambda的闭包对象、访问器的临时实例）的布局或生命周期处理不当导致的，而非你的业务逻辑写错了。

2. C++20是否引入了相关修正？ #

是的，C++20对lambda和std::visit的处理有两处关键改进，正好能规避这个问题：

• lambda模板化调用运算符的规范强化：C20明确了无捕获lambda的模板化operator()的类型推导和内存布局规则，解决了C17中编译器处理这类lambda时的模糊点。
• std::visit的参数处理优化：C++20对std::visit的多态函数对象（比如overload组合的lambda）实例化逻辑做了修正，减少了临时对象生成时可能出现的内存布局错误。

这些标准层面的调整，让MSVC在C++20模式下能正确处理无捕获泛型lambda的场景，不会触发栈损坏检测。

3. 是否是MSVC C++17 Debug的特殊bug？ #

可以确定这是MSVC在C++17 Debug模式下的实现bug，原因如下：

• 仅在Debug模式触发：Debug模式下MSVC会插入栈保护、内存初始化等检查代码，编译器在生成无捕获泛型lambda的闭包对象时，可能错误计算了栈空间大小，或在overload组合器的实例化过程中出现内存越写，触发了栈保护检测。
• 添加捕获后异常消失：带捕获的lambda闭包对象类型和内存布局与无捕获lambda不同，编译器对这类lambda的处理逻辑更成熟，避开了之前的瑕疵。
• 切换到C20后异常消失：C20的标准修正让编译器的处理逻辑符合新规范，自然消除了这个bug。

C++17 Debug模式下的临时规避方案：

• 给默认处理的lambda添加无意义捕获（比如[dummy=0]()）
• 将默认处理的lambda替换为普通模板函数对象

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