在C風格中搜索顯式類型轉換：a =（int）b;

Question

我有一個關於這種診斷的好處的問題。 一位用戶建議我們在PVS-Studio分析器中實現了C風格的所有顯式類型轉換的搜索。 也就是說，檢測這種結構的診斷：

int *x = (int *)y;
float a = float(b);
float c = (float)(d);

其目的是用更安全的版本替換所有這些轉換 - reinterpret_cast / static_cast / const_cast。 在這種重構過程中，可能會檢測到代碼中的一些缺陷。

當然，這不是檢測到關鍵錯誤，如果我們實施此診斷，它將在[客戶的特定請求]部分中並默認禁用。

但我甚至懷疑這種診斷的好處。 所以我決定問其他用戶：其他人是否需要這個選項來搜索C風格的顯式類型轉換？ 有人想在他們的代碼中執行這種重構嗎？

Answer 1

一個共同的觀點（例如由Stroustrup表達 ）是C風格的演員表容易隱藏錯誤。 我認為這些觀點會激勵很多人不使用它們，所以我認為反C-cast診斷會得到一些用處。 我個人不會這樣做，因為我無論如何都避免使用C風格的演員，但鑒於遺留代碼，我發現搜索很有用。

Answer 2

我甚至會走得更遠，一般來說演員是一件壞事，使用它們的代碼很多都是可疑的。 這當然是C的情況，其中可能發生的隱式轉換的規則非常有限並且由語言很好地定義。

由於重載，C ++有點復雜，但是，你不應該需要很多顯式的強制轉換。 設計應該總是這樣，有一個唯一的路徑將一種類型轉換為另一種類型。

轉換很糟糕，因為如果轉換表達式的類型發生更改，它們很容易隱藏問題。 在您的示例中，例如， y從指針類型更改為整數類型。 但無論如何，C ++風格的演員陣容要好得多，不管它們是否更易於搜索，而且輸入真是一種痛苦，人們自然會避免它們:)並且只是試圖完全禁止reinterpret_cast或者至少它應該真的很少見。

Answer 3

我理解C ++的動機傾向於C cast（主要是因為C cast有時是static_cast，有時是reinterpret_cast，有驚喜的風險）但是......重構已經有效的東西可能會引入意想不到的錯誤，僅僅因為你可能誤解了什么最初的開發人員要做...

除非你正在重新考慮重寫邏輯（所以你不是在“聲明語句”，而是理解整體語義），否則我不會這樣做。

Answer 4

有沒有其他人需要這個選項來搜索C風格的顯式類型轉換？

是。 這是引入/隱藏錯誤的簡單方法（例如，程序的最直接更新可能會產生一些警告或錯誤）。

我贊成cpp樣式演員，因為它們是眼睛，而c樣式演員很容易被模糊（這是設計）。

更好的是，通過整個過程並將程序修復為類型安全（大多數鑄件在cpp中是不必要的）通常是更好的解決方案。

有人想在他們的代碼中執行這種重構嗎？

我擺脫了所有舊式的演員陣容並沿途堅持（一些錯誤）。 我更開心 根據您的代碼庫和您構建它的開發人員的信任程度，它可能不是很好用的時間。 這是一個無聊的過程，但時間可能最終被用於調試theta被屏蔽的問題（再次，取決於代碼庫）。