C ++ 20 bit_cast与reinterpret_cast [英] C++20 bit_cast vs reinterpret_cast

问题描述

根据ISO C ++委员会的上次会议，

According to the last meeting of the ISO C++ Committee, bit-cast will be introduced in C++20 standard.

由于类型别名，我知道reinterpret_cast不适合该工作规则，但是我的问题是为什么他们为什么不选择不扩展reinterpret_cast来将对象像位序列表示一样对待，而是倾向于将此功能作为一种新的语言构造来提供?

I know that reinterpret_cast is not suitable for this job due to type aliasing rules but my question is why did they choose not to extend the reinterpret_cast to treat the object like it bit sequence representation and preferred to give this functionality as a new language construct?

推荐答案

好吧，有一个明显的原因:因为它无法完成bit_cast的所有工作.即使在我们可以在编译时分配内存的C ++ 20世界中，constexpr函数中也禁止使用reinterpret_cast. bit_cast的明确目标之一是能够在编译时执行以下操作:

Well, there is one obvious reason: because it wouldn't do everything that bit_cast does. Even in the C++20 world where we can allocate memory at compile time, reinterpret_cast is forbidden in constexpr functions. One of the explicit goals of bit_cast is to be able to do these sorts of things at compile-time:

此外，由于memcpy本身不是constexpr，因此目前无法实现constexpr位广播功能.将建议的功能标记为constexpr并不需要或防止memcpy成为constexpr，但是需要编译器支持.这样一来，实施人员就可以自由使用自己的内部解决方案(例如LLVM具有bitcast操作码).

Furthermore, it is currently impossible to implement a constexpr bit-cast function, as memcpy itself isn’t constexpr. Marking the proposed function as constexpr doesn’t require or prevent memcpy from becoming constexpr, but requires compiler support. This leaves implementations free to use their own internal solution (e.g. LLVM has a bitcast opcode).

现在，您可以说可以将reinterpret_cast的特定用法扩展到constexpr上下文.但这使规则变得复杂.您不仅要记住reinterpret_cast在constexpr代码期内不能使用，还必须记住reinterpret_cast不能使用的特定形式.

Now, you could say that you could just extend this specific usage of reinterpret_cast to constexpr contexts. But that makes the rules complicated. Instead of simply knowing that reinterpret_cast can't be used in constexpr code period, you have to remember the specific forms of reinterpret_cast that can't be used.

此外，还有一些实际问题.即使您想走reinterpret_cast路线，std::bit_cast也是一个库函数.通过委员会获得图书馆功能总是比语言功能容易，即使它会得到一些编译器支持.

Also, there are practical concerns. Even if you wanted to go the reinterpret_cast route, std::bit_cast is a library function. And it's always easier to get a library feature through the committee than a language feature, even if it would receive some compiler support.

然后是更多主观的东西. reinterpret_cast通常被认为是一种固有的危险操作，表明以某种方式欺骗"了类型系统.相反，bit_cast不是.它正在生成一个新对象，就像通过从现有对象复制其值表示形式一样.这是一个低级工具，但不是与类型系统混淆的工具.因此，以与拼写危险"操作相同的方式拼写安全"操作会很奇怪.

Then there's the more subjective stuff. reinterpret_cast is generally considered an inherently dangerous operation, indicative of "cheating" the type system in some way. By contrast, bit_cast is not. It is generating a new object as if by copying its value representation from an existing one. It's a low-level tool, but it's not a tool that messes with the type system. So it would be strange to spell a "safe" operation the same way you spell a "dangerous" one.

实际上，如果您以相同的方式拼写它们，则会开始引起人们对为什么定义合理定义的疑问:

Indeed, if you did spell them the same way, it starts raising questions as to why this is reasonably well-defined:

float f = 20.4f;
int i = reinterpret_cast<int>(f);

但是这有点不好:

float f = 20.4f;
int &i = reinterpret_cast<int &>(f);

并且可以肯定的是，语言律师或熟悉严格的别名规则的人会理解为什么后者不好.但是对于外行人来说，如果可以使用reinterpret_cast进行位转换，则不清楚为什么使用reinterpret_cast转换指针/引用并将现有对象解释为转换类型是错误的.

And sure, a language lawyer or someone familiar with the strict aliasing rule would understand why the latter is bad. But for the lay person, if it is fine to use reinterpret_cast to do a bit-conversion, it is unclear why it is wrong to use reinterpret_cast to convert pointers/references and interpret an existing object as a converted type.

不同的工具应使用不同的拼写.

Different tools should be spelled differently.

这篇关于C ++ 20 bit_cast与reinterpret_cast的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！