C++ 固定大小的浮点类型
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2524737/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Fixed-size floating point types
提问by Pietro
In the stdint.h(C99), boost/cstdint.hpp, and cstdint(C++0x) headers there is, among others, the type int32_t.
在stdint.h(C99)、boost/cstdint.hpp和cstdint(C++0x) 头文件中，还有 type int32_t。
Are there similar fixed-size floating point types? Something like float32_t?
是否有类似的固定大小浮点类型？像float32_t什么？
采纳答案by Stephen Canon
Nothing like this exists in the C or C++ standards at present. In fact, there isn't even a guarantee that floatwill be a binary floating-point format at all.
目前在 C 或 C++ 标准中不存在这样的东西。事实上，甚至根本不能保证float将是二进制浮点格式。
Some compilers guarantee that the floattype will be the IEEE-754 32 bit binary format. Some do not. In reality, floatis in fact the IEEE-754 singletype on mostnon-embedded platforms, though the usual caveats about some compilers evaluating expressions in a wider format apply.
一些编译器保证float类型将是 IEEE-754 32 位二进制格式。有些没有。实际上，float实际上是大多数非嵌入式平台single上的 IEEE-754类型，尽管有关某些编译器以更广泛的格式评估表达式的通常警告适用。
There is a working group discussing adding C language bindings for the 2008 revision of IEEE-754, which could consider recommending that such a typedef be added. If this were added to C, I expect the C++ standard would follow suit... eventually.
有一个工作组正在讨论为 IEEE-754 的 2008 修订版添加 C 语言绑定，可以考虑建议添加这样的 typedef。如果将其添加到 C 中，我希望 C++ 标准会效仿……最终。
回答by Potatoswatter
If you want to know whether your floatis the IEEE 32-bit type, check std::numeric_limits<float>::is_iec559. It's a compile-time constant, not a function.
如果您想知道您是否float是 IEEE 32 位类型，请检查std::numeric_limits<float>::is_iec559。它是一个编译时常量，而不是一个函数。
If you want to be more bulletproof, also check std::numeric_limits<float>::digitsto make sure they aren't sneakily using the IEEE standard double-precision for float. It should be 24.
如果您想更加防弹，还要检查std::numeric_limits<float>::digits以确保它们没有偷偷地使用 IEEE 标准双精度 for float. 应该是24。
When it comes to long double, it's more important to check digitsbecause there are a couple IEEE formats which it might reasonably be: 128 bits (digits = 113) or 80 bits (digits = 64).
当谈到 时long double，检查更重要，digits因为有几种 IEEE 格式可能是合理的：128 位（数字 = 113）或 80 位（数字 = 64）。
It wouldn't be practical to have float32_tas such because you usually want to use floating-point hardware, if available, and not to fall back on a software implementation.
这样做是不切实际的，float32_t因为您通常希望使用浮点硬件（如果可用），而不是依靠软件实现。
回答by EmbeddedCoder
If you think having typedefs such as float32_t and float64_t are impractical for any reasons, you must be too accustomed to your familiar OS, compiler, that you are unable too look outside your little nest.
如果您认为使用诸如 float32_t 和 float64_t 之类的 typedef 出于任何原因是不切实际的，那么您一定太习惯于熟悉的操作系统、编译器，以至于您无法在自己的小窝之外看。
There exist hardware which natively runs 32-bit IEEE floating point operations and others that do 64-bit. Sometimes such systems even have to talk to eachother, in which case it is extremely important to know if a double is 32 bit or 64 bit on each platform. If the 32-bit platform were to do excessive calculations on base on the 64-bit values from the other, we may want to cast to the lower precision depending on timing and speed requirements.
存在本机运行 32 位 IEEE 浮点运算的硬件和其他运行 64 位的硬件。有时，此类系统甚至必须相互通信，在这种情况下，了解每个平台上的 double 是 32 位还是 64 位非常重要。如果 32 位平台基于来自其他平台的 64 位值进行过多计算，我们可能希望根据时序和速度要求转换为较低的精度。
I personally feel uncomfortable using floats and doubles unless I know exactly how many bits they are on my platfrom. Even more so if I am to transfer these to another platform over some communications channel.
我个人对使用浮动和双打感到不舒服，除非我确切地知道它们在我的平台上有多少位。如果我要通过某些通信渠道将这些传输到另一个平台，则更是如此。
回答by Trevor Hickey
There is currently a proposal to add the following types into the language:
目前有一项建议将以下类型添加到语言中：
decimal32
decimal64
decimal128
which may one day be accessible through #include <decimal>.
有朝一日可以通过#include <decimal>.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.html
