c++ - 为什么 std::uncaught_exception 会变成 std​​::uncaught_exceptions？

Question

我刚刚注意到了

http://en.cppreference.com/w/cpp/error/uncaught_exception

C++17 将用 std::uncaught_exceptions() 替换返回 bool 的 std::uncaught_exception() ，它返回一个 int。

对此标准的补充说明如下:

http://isocpp.org/files/papers/n4259.pdf

它没有提供理由，但确实说明了

[Note: When uncaught_exceptions() > 0, throwing an exception can result in a call of std::terminate() (15.5.1). – end note]

这有点奇怪。

这种变化的原因是什么？在 C++17 或该标准的某些 future 版本中是否会出现多个事件异常？

Answer 1

介绍这个的论文是n4152 ，有其基本原理(通常归结为“使 ScopeGuard 工作”)

引用，

as documented at least since 1998 in Guru of the Week #47, it means code that is transitively called from a destructor that could itself be invoked during stack unwinding cannot correctly detect whether it itself is actually being called as part of unwinding. Once you’re in unwinding of any exception, to uncaught_exception everything looks like unwinding, even if there is more than one active exception.

和

this uses information already present in major implementations, where current implementations of ScopeGuard resort to nonportable code that relies on undocumented compiler features to make ScopeGuard “portable in practice” today. This option proposes adding a single new function to expose the information that already present in compilers, so that these uses can be truly portable

PS:下面是如何使用编译器特定信息实现此功能的示例:https://github.com/panaseleus/stack_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp

对于一个使用它的简单示例，只需查看 boost.log 的“记录泵”(参见 boost/log/detail/format.hpp 和 boost/log/sources/record_ostream.hpp):它使 BOOST_LOG(lg) << foo(); 成为可能如果 foo 则登录它创建的保护对象的析构函数不抛出，也就是说，如果调用析构函数时发生的异常数量不大于调用构造函数时的异常数。