reinterpret_cast 演員成本

Question

我的理解是 C++ reinterpret_cast 和 C 指針轉換只是一個編譯時功能，它根本沒有性能成本。

這是真的？

Answer 1

這是一個很好的假設。 但是，優化器在存在reinterpret_cast<>或 C 指針reinterpret_cast<>的情況下可能會受到限制。 然后，即使強制轉換本身沒有關聯的指令，生成的代碼也會更慢。

例如，如果您將 int 轉換為指針，優化器可能不知道該指針可能指向什么。 因此，它可能必須假設通過該指針的寫入可以更改任何變量。 這擊敗了非常常見的優化，例如將變量存儲在寄存器中。

Answer 2

這是正確的。 除了在新寬度下執行指令的任何性能增益/損失之外，沒有任何成本，我可能會添加，這只是在極少數情況下的一個問題。 在我聽說過的每個平台上的指針之間進行轉換都是零成本的，並且沒有任何性能變化。

Answer 3

C++ 中的 C 風格強制轉換將首先嘗試 static_cast，只有在無法執行靜態強制轉換時才執行 reinterpret_cast。 在多重繼承的情況下（或將接口轉換為具體類型時），static_cast 可能會改變指針的值，這種偏移計算可能涉及額外的機器指令。 這最多是 1 條機器指令，因此非常小。

Answer 4

是的，這是真的。 具有運行時成本的轉換類型是 dynamic_cast。

Answer 5

你是對的，但想想看：reinterpret_cast 意味着可能是一個糟糕的設計，或者你正在做一些非常低級的事情。

動態轉換相反它會花費你一些東西，因為它必須在運行時查看查找表。

Answer 6

reinterpret_cast不會產生運行時成本......但是你必須小心，因為reinterpret_cast每次使用都是實現定義的。 例如，將char數組重新解釋為int數組可能會導致目標架構拋出中斷，因為不同的類型可能具有不同的對齊規則。

先做對，再考慮效率。

Answer 7

在重新解釋將有符號字符轉換為無符號字符之前和之后，我都在查看我的匯編代碼。 指令增加了大約 3 或 4 條指令。

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

我正在轉換為 unsigned char 以使編譯器使用 SHL 指令，而不是 SAR 指令，以便新移位的位移位將是 zer0s 而不是 var i 有符號位值。

編譯器仍然並且似乎總是使用 SAR 指令。 但是重新解釋轉換使編譯器添加了更多指令。 還有 3 到 4 個說明！

我擔心為什么我的用於將 UTF8 轉換為 UTF16 字符串的 unicode 函數比 Win32 MultiByteToWideChar() 慢了近 3 倍。 現在我擔心選角是主要因素之一。

這是具有諷刺意味的，因為我們使用重新解釋轉換來提高速度。