为什么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_exceptions（），返回 bool $ c>，它返回一个 int 。

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

它不提供理由，但它说

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

这是奇怪的模糊。

改变的原因？在C ++ 17或标准的某个未来版本中，多个活动异常是否可能？

解决方案

n4152 ，其理由（通常归结为make ScopeGuard work）

引用

自1998年以来，在第47周的大师中，它意味着从析构函数中被过渡调用的代码，它本身可以在堆栈解开期间被调用，不能正确地检测它本身是否实际上被称为展开的一部分。一旦你解开任何异常， uncaught_exception 一切看起来像放松，即使有一个以上的活动异常。

和

这使用主要实现中已经存在的信息，其中ScopeGuard借助于非可移植代码，它依赖无证的编译器特性，使ScopeGuard在实践中可移植。此选项建议添加一个新函数以公开已存在于编译器中的信息，以便这些用途可以真正可移植。

PS ：以下是使用编译器特定信息实现此函数的示例： https：/ /github.com/panaseleus/stack_unwinding/blob/master/boost/exception/uncaught_exception_count.hpp

对于使用它的简单示例，请查看no远远超过boost.log的记录泵（请参阅​​ boost / log /detail/format.hpp 和 boost / log /sources/record_ostream.hpp ）：它使得 BOOST_LOG（lg）<<如果 foo 不抛出，foo（）; 登录它创建的guard对象的析构函数，在调用析构函数时不大于调用构造函数时。

I just noticed over on

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

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

The addition to the standard describing this is here:

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

It doesn't provide the rationale but it does say

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

which is oddly vague.

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

解决方案

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

To quote,

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.

And

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: 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

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屋！