parseInt（）和parseFloat（）：第二個斷言能否失敗？

我已經在各種環境下使用parseInt()和parseFloat()已經有一段時間了，我想我認爲我知道這兩者的所有細節。但最近我有一個奇怪的想法，我迄今還沒有能夠明確地找出一個證明。parseInt（）和parseFloat（）：第二個斷言能否失敗？

考慮以下功能：

function testProof(strInteger) { 
    assert(strInteger === '' + parseInt(strInteger, 10)); 

    assert(parseInt(strInteger, 10) === parseFloat(strInteger)); 
} 

// Sample calls... 
testProof("5"); 
testProof("109"); 
testProof("-55");

首先我們assert的輸入轉換爲整數，然後轉換回字符串再次生成原始字符串。這防止parseInt("100bucks")返回100的情況，並且它還確保沒有小數部分被轉換截斷 - 我們要確保輸入實際上是整數，整數字符串。

如果成功，我們assert即parseInt(..., 10)返回與parseFloat(...)相同的值。

有很多原因，第一assert會失敗：

輸入不是一個整數（"1.5"）
輸入具有前導零（"0050"）
輸入具有尾隨垃圾（"100bucks"）
輸入爲指數表示法（"1e3"），或者它如此之大以致變成指數式
輸入不可解析，導致NaN
也許別人？

但這裏有一個問題：只要第一assert通行證，可以在第二assert曾經失敗？換句話說，如果我們提前知道輸入是一個字符串內的整數，那麼parseFloat(...)可以作爲parseInt(..., 10)的插入替換函數嗎？（不是說這是一個很好的更換 ... :-P）

來源

2014-07-25 smitelli

它實際上只能用這個輸入失敗：

testProof("NaN");

但如果你真的知道這是一個整數，測試爲何？另外parseFloat不能很好地替代parseInt，因爲在許多情況下你不知道它是否是一個整數而不是浮點數。

來源

2014-07-25 18:20:48 Razem

好抓！我從來沒有考慮嘗試一個字面的「NaN」。我同意，這可能是不應該做的事情;這更多的是理論上的好奇心，看看是否存在兩種行爲不同的邊緣情況。 – smitelli

@smitelli那麼，只有當你不知道字符串裏面的內容時，它們的行爲纔會有所不同。另一方面，如果你確信它是一個字符串化的整數，那麼只需執行'+ str'或'str * 1'就容易了。 – Razem

-1

雖然我不能提供一個證明，JS沒有整數和浮點數之間的區別。 parseFloat和parseInt之間的唯一區別是它們如何解釋諸如小數點之類的東西。但是，如果輸入的字符串是一個有規則的符號形式的整數，那麼它們總是會導致相同的數值，這在JS中意味着它們的類型也是相同的。

來源

2014-07-25 18:24:20

parseInt（）和parseFloat（）：第二個斷言能否失敗？

回答

相關問題