为什么会std :: uncaught_exception改为std :: uncaught_exceptions？ [英] Why will std::uncaught_exception change to std::uncaught_exceptions?

问题描述

我刚刚注意到了

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

C ++ 17将替换 std :: uncaught_exception（），它返回一个 bool ，其中 std :: uncaught_exceptions（），它返回一个 int 。

that C++17 will replace std::uncaught_exception(), which returns a bool, with std::uncaught_exceptions(), which returns an int.

添加标准描述这里是：

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

它不提供理由，但它确实说

It doesn't provide the rationale but it does say

[注意：当uncaught_exceptions（）> 0时，抛出异常可以
导致std :: terminate（）（15.5.1）的调用。 - 结束笔记]

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

这是奇怪的模糊。

改变的原因？在C ++ 17或某些未来版本的标准中会有多个活动异常吗？

What is the reason for this change? Will multiple active exceptions be possible in C++17 or some future version of the standard?

推荐答案

n4152 ，其理由（一般归结为使ScopeGuard工作）

The paper that introduced this was n4152, which has the rationale (which generally boils down to "make ScopeGuard work")

引用

至少记录自1998年第47周的大师以来，这意味着从堆栈展开本身可以调用的析构函数传递的代码无法正确检测其本身是否实际被调用作为展开的一部分。一旦你正在解除任何例外，即使有多个活动的例外， c> uncaught_exception 一切都看起来像放松，

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.

和

这使用了主要实现中已经存在的信息，其中ScopeGuard的当前实现使用依赖于未记录的编译器功能的非可移植代码，使ScopeGuard今天实用。此选项建议添加一个新功能来公开编译器中已经存在的信息，以便这些用途可以真正实现。

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

PS: Here's an example of how this function can be implemented using compiler-speicific information: 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 不抛出，也就是说，如果异常数当调用析构函数时，在调用构造函数时不大于空值。

And for a simple example where it's used, look no further than boost.log's "record pump" (see boost/log/detail/format.hpp and boost/log/sources/record_ostream.hpp): it makes it possible for BOOST_LOG(lg) << foo(); to log in the destructor of the guard object it creates if foo doesn't throw, that is, if the number of exceptions in flight when the destructor is called is not greater than when the constructor was called.

这篇关于为什么会std :: uncaught_exception改为std :: uncaught_exceptions？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！