std::underflow_error
来自 cppreference.cn
| 定义于头文件 <stdexcept> |
||
| class underflow_error; |
||
定义一种作为异常抛出的对象类型。它可用于报告算术下溢错误（即计算结果为次正规浮点值的情况）。
标准库组件不会抛出此异常（数学函数会按照 math_errhandling 中的规定报告下溢错误）。但是，第三方库会使用此异常。例如，如果启用了 `boost::math::policies::throw_on_error`（默认设置），boost.math 会抛出 `std::underflow_error`。
继承图
目录 |
[编辑] 成员函数
| (构造函数) |
使用给定消息构造新的 `underflow_error` 对象 (公开成员函数) |
| operator= |
替换 `underflow_error` 对象 (公开成员函数) |
std::underflow_error::underflow_error
| underflow_error( const std::string& what_arg ); |
(1) | |
| underflow_error( const char* what_arg ); |
(2) | |
| underflow_error( const underflow_error& other ); |
(3) | (C++11 起无异常抛出) |
3) 复制构造函数。如果 *this 和 other 都具有动态类型 `std::underflow_error`，则 std::strcmp(what(), other.what()) == 0。复制构造函数不能抛出异常。
参数
| what_arg | - | 解释性字符串 |
| 其他 | - | 要拷贝的另一个异常对象 |
异常
1,2) 可能抛出 std::bad_alloc。
注意
因为不允许复制 `std::underflow_error` 抛出异常，所以此消息通常以单独分配的引用计数字符串的形式在内部存储。这也是为什么没有接受 `std::string&&` 的构造函数：它无论如何都必须复制内容。
在 LWG issue 254 解决之前，非复制构造函数只能接受 std::string。为了构造 std::string 对象，这使得动态内存分配成为强制要求。
在 LWG issue 471 解决之后，派生标准异常类必须具有可公开访问的复制构造函数。只要通过 `what()` 获取的解释字符串对于原始对象和复制对象相同，就可以隐式定义它。
std::underflow_error::operator=
| underflow_error& operator=( const underflow_error& other ); |
(C++11 起无异常抛出) | |
用 other 的内容赋值。如果 *this 和 other 都具有动态类型 `std::underflow_error`，则赋值后 std::strcmp(what(), other.what()) == 0。复制赋值运算符不能抛出异常。
参数
| 其他 | - | 用于赋值的另一个异常对象 |
返回值
*this
注意
在 LWG issue 471 解决之后，派生标准异常类必须具有可公开访问的复制赋值运算符。只要通过 `what()` 获取的解释字符串对于原始对象和复制对象相同，就可以隐式定义它。
继承自 std::exception
成员函数
| [虚] |
销毁异常对象 （`std::exception` 的虚公共成员函数） |
| [虚] |
返回解释字符串 （`std::exception` 的虚公共成员函数） |
[编辑] 缺陷报告
下列更改行为的缺陷报告追溯地应用于以前出版的 C++ 标准。
| 缺陷报告 | 应用于 | 发布时的行为 | 正确的行为 |
|---|---|---|---|
| LWG 254 | C++98 | 缺少接受 const char* 的构造函数 | 已添加 |
| LWG 471 | C++98 | `std::underflow_error` 的解释字符串 解释性字符串是实现定义的 |
它们与原始 std::runtime_error 对象的原始 `std::underflow_error` 对象 |
