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

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

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

其目的是與他們的安全版本替換所有這些轉換 - 的reinterpret_cast /的static_cast/const_cast會。在這種重構的過程期間，代碼中的一些缺陷可能被很好地檢測到。

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

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

來源

2011-09-28 user34341

'float a = float（b）;'不是C風格的演員。這個語法由C++引入。 – Nawaz

@Nawaz但是它的語義與C風格的演員*相同，因此它有相同的問題。 –

如果你的風格指南說，「不要使用C風格的演員」，那麼能夠以自動化的方式強制執行該風格將是有用的。要求分析免於此類警告將實現該目標，所以對於任何想避免它們（即使它們不是重構）的人都是有用的。 –

一個常見的視圖（例如expressed by Stroustrup）是C風格的轉換容易隱藏錯誤。我猜想這些觀點會激勵相當多的人不使用它們，所以我猜，反C語言診斷會得到一些用法。我個人不會這麼做，因爲我避免使用C風格的演員，但是考慮到遺留代碼，我會發現搜索很有用。

來源

2011-09-28 12:20:50 thiton

我甚至會走得更遠，一般而言，施法是一件壞事，使用它們的代碼很多都是可疑的。對於C來說，情況確實如此，其中可能發生的隱式轉換的規則非常有限，並且由語言明確定義。

由於重載，C++會稍微複雜一點，但仍然不需要太多明確的轉換。一個設計應該始終保證有一條獨特的路徑將一種類型轉換爲另一種類型。

投射不好，因爲如果投射的表達式的類型改變，它們很容易隱藏問題。在你的示例中，例如，如果y從指針類型更改爲整數類型。但是在任何情況下，C++風格的轉換都要好得多，不管怎樣，他們都更容易搜索，而且確實是一種很痛苦的輸入方式，人們自然會避免它們:)並且試圖完全禁止reinterpret_cast或至少它應該是非常罕見的。

來源

2011-09-28 12:35:44

我明白C++傾向於使用C cast的動機（主要是因爲C cast有時候是static_cast，有時候是reinterpret_cast，有可能會有驚喜）但是......重構已經有效的東西可能會引入一些意想不到的錯誤，你可能會誤解最初的開發人員會做什麼...

除非你重新考慮重寫邏輯（所以你不是在工作「聲明語句」，而是理解整體語義），我不會這樣做。

來源

2011-09-28 12:36:03

@KillianDS：當然是！特別是如果它不是「我的」代碼，而是那些從幾年開始的事情，並且已經由不同風格的開發人員維護。工具和庫/編譯器的年齡。遲早會重新考慮整個代碼，而不是「調整」它。在那個sanse是我的帖子！ –

是否有其他人需要此選項來搜索C風格的顯式類型轉換？

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

我喜歡cpp風格演員，因爲他們是眼睛，而c風格演員很容易被模糊（這是設計）。

更好的是，通過該過程並將程序固定爲類型安全（大多數鑄造在cpp中是不必要的）通常是更好的解決方案。

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

我擺脫所有的舊風格的轉換，並堅持了下來沿途的（一些bug以及）。我更開心。取決於您的代碼庫和您構建它的開發人員的信任級別，這可能不是一個很好的時間使用。這是一個無聊的過程，但時間可能最終會花費在調試theta被屏蔽的問題上（再次，取決於代碼庫）。

來源

2011-09-28 12:39:45 justin

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

回答

相關問題