重新解释铸造成本

这是一个很好的假设。但是,优化器可能会受到限制,无法在存在 reinterpret_cast<>

例如,如果将int转换为指针,优化器可能不知道该指针可能指向什么。因此,它可能必须假设通过该指针的写操作可以更改任何变量。这击败了非常常见的优化,例如将变量存储在寄存器中。

这是正确的。在新的宽度上执行指令,除了性能上的任何增益/损失之外,没有其他成本(我可能会补充一点),这只是少数情况下的一个问题。在我听说过的每个平台上,指针之间的转换都是零成本的,而且性能没有任何变化。

C++中的C样式强制将首先尝试静态分析,如果不能执行静态映射,则只执行重新解释。在多重继承的情况下(或当将接口转换为具体类型时),静态类型转换可能会更改指针的值,此偏移量计算可能会涉及额外的机器指令。这最多只能是一条机器指令,所以真的很小。

你是对的,但是想想看:重新解释一下你的角色可能意味着一个糟糕的设计或者你在做一些非常低级的事情。

相反,动态强制转换将花费您一些东西,因为它必须在运行时查找查找表。

reinterpret_cast 不会产生运行时成本。。但是你要小心,因为 重新解释 char int 数组可能导致目标体系结构抛出一个中断,因为不同的类型可能有不同的对齐规则。

先正确,再担心效率。

在将有符号字符转换为无符号字符之前和之后,我都在查看我的汇编代码。指令增加了3到4条指令。

int main()
{
 signed char i = 0x80;
 (unsigned char&)i >>= 7;
 return i;
}

我强制转换为unsigned char以使编译器使用SHL指令,而不是SAR指令,这样新移位的位将是zer0s,而不是var I signed bit value。

编译器仍然并且似乎总是使用SAR指令。但是重新解释铸造使编译器添加了更多的指令。还有3到4条指令!

我很担心为什么我的unicode函数将UTF8转换成UTF16字符串的速度几乎比Win32 MultiByteToWideChar()慢3倍。现在我担心铸造是主要因素之一。

这是讽刺,因为我们使用的速度重新解释铸造。