編寫0.0，0.0f或.0f而不是簡單的0爲假設的浮點數或雙精度值是否更好

Question

你好，以及所有的標題。這個問題特別適用於所有那些可能類似於NSTimeInterval,CGFloat或任何其他變量的浮點數或雙精度值。謝謝。

編輯：我要求賦值的格式不是字符串。

編輯2：問題是真的爲浮點數指定一個普通的0或者雙精度比最後的任何值都要差f。

Answer 1

的基本區別是：

1.0或1.是雙恆定

1.0f被浮子恆定

如果沒有一個後綴，一個文字在它的十進制（123.0）將是視爲雙精度浮點數。如果您將其分配或傳遞給單精度變量或參數，編譯器將（應該）發出警告。追加f告訴編譯器您希望文字被視爲單精度浮點數。

Answer 2

如果您想要挖掘出與目標CPU運行的代碼或執行的二進制代碼有什麼不同，您可以輕鬆地將從XCode編譯代碼的命令行之一複製到命令行，修復缺少的環境變量並添加-S。通過這個，你將得到程序集輸出，你可以用它來比較。如果將所有4個變體放在一個小的示例源文件中，那麼即使沒有流利的ARM彙編，您也可以比較後來生成的彙編代碼。

從我的ARM彙編經驗（好吧...... 6年前和GCC）我敢打賭1CT上像XOR置寄存器本身刷新它的內容爲0。

Answer 3

無論您使用的0.0，0.0 ，或者0.0f甚至0f並沒有太大區別。 （有一些關於double和float）你甚至可以使用（float）0.

但是0和某些浮點表示法之間存在顯着差異。零總是某種類型的整數。這可以強制機器執行整數操作，而您可能需要浮動操作。

我沒有一個好方便的例子，但我有一個一般的float/int，nealy讓我瘋狂的前一天。

我習慣於8位RGB顏色這是因爲我的愛好攝影師，因爲我最近的背景爲HTML開發人員。所以我覺得很難習慣可可風格0..1分數的紅色，綠色和黃色。爲了克服，我想用255

[CGColor colorWithRed: 128/255 green: 128/255 andYellow: 128/255]; 

使用，我是用的價值和devide他們應該產生我一些很好的中間灰色。但事實並非如此。我試過的所有東西都是黑色或白色。 首先，我認爲這是由於我使用這種顏色的UI文本對象的某些未公開的缺陷造成的。花了一段時間才意識到，這個常數值強制整數運算只能四捨五入到0和1。 這expession最終做了什麼，我想實現：

[CGColor colorWithRed: 128.0/255.0 green: 128.0/255.0 andYellow: 128.0/255.0]; 

你可以實現與附着較少.0s同樣的事情。但如果需要的話，它不會傷害更多人。 128.0f /（float）255會做。

編輯回覆您的 「EDIT2」：

float fvar; 
fvar = 0; 

VS ...

fvar = .0; 

最終不會有所作爲的。 fvar將包含接近（但不總是等於）0.0的浮點值。對於第60屆和第70屆編譯器，我會猜想有一個與fvar = 0相關的性能問題。那就是編譯器首先創建一個int 0，然後必須在賦值之前將其轉換爲float。今天的現代編譯器應該比舊版編譯器自動優化得更好。最後，我必須查看機器代碼輸出以查看它是否有所作爲。 但是，使用fvar = .0;時，您始終處於安全地點。

Answer 4

如果你正在初始化一個變量，那麼它沒有任何意義。編譯器爲你做所有投射。

float a = 0; //Cast int 0 to float 0.0 
float b = 0.0; //Cast 0.0 double to float 0.0 as by default floating point constants are double 
float c = 0.0f // Assigning float to float. .0f is same as 0.0f 

但是，如果你在一個表達中使用這些，那麼這很有意義。

6/5 becomes 1 
6/5.0 becomes 1.2 (double value) 
6/5.0f becomes 1.2 (float value)