when to use which
What are the differences between this line:
var a = parseInt("1", 10); // a === 1
and this line
var a = +"1"; // a === 1
This jsperf test shows that the unary operator is much faster in the current chrome version, assuming it is for node.js!?
If I try to convert strings which are not numbers both return NaN
:
var b = parseInt("test" 10); // b === NaN
var b = +"test"; // b === NaN
So when should I prefer using parseInt
over the unary plus (especially in node.js)???
edit : and what's the difference to the double tilde operator ~~
?
Please see this answer for a more complete set of cases
Well, here are a few differences I know of:
An empty string ""
evaluates to a 0
, while parseInt
evaluates it to NaN
. IMO, a blank string should be a NaN
.
+'' === 0; //true
isNaN(parseInt('',10)); //true
The unary +
acts more like parseFloat
since it also accepts decimals.
parseInt
on the other hand stops parsing when it sees a non-numerical character, like the period that is intended to be a decimal point .
.
+'2.3' === 2.3; //true
parseInt('2.3',10) === 2; //true
parseInt
and parseFloat
parses and builds the string left to right. If they see an invalid character, it returns what has been parsed (if any) as a number, and NaN
if none was parsed as a number.
The unary +
on the other hand will return NaN
if the entire string is non-convertible to a number.
parseInt('2a',10) === 2; //true
parseFloat('2a') === 2; //true
isNan(+'2a'); //true
As seen in the comment of @Alex K., parseInt
and parseFloat
will parse by character. This means hex and exponent notations will fail since the x
and e
are treated as non-numerical components (at least on base10).
The unary +
will convert them properly though.
parseInt('2e3',10) === 2; //true. This is supposed to be 2000
+'2e3' === 2000; //true. This one's correct.
parseInt("0xf", 10) === 0; //true. This is supposed to be 15
+'0xf' === 15; //true. This one's correct.
The ultimate whatever-to-number conversion table:
EXPRS = [
'parseInt(x)',
'parseFloat(x)',
'Number(x)',
'+x',
'~~x',
'x>>>0',
'isNaN(x)'
];
VALUES = [
'"123"',
'"+123"',
'"-123"',
'"123.45"',
'"-123.45"',
'"12e5"',
'"12e-5"',
'"0123"',
'"0000123"',
'"0b111"',
'"0o10"',
'"0xBABE"',
'"4294967295"',
'"123456789012345678"',
'"12e999"',
'""',
'"123foo"',
'"123.45foo"',
'" 123 "',
'"foo"',
'"12e"',
'"0b567"',
'"0o999"',
'"0xFUZZ"',
'"+0"',
'"-0"',
'"Infinity"',
'"+Infinity"',
'"-Infinity"',
'null',
'[].undef',
'true',
'false',
'Infinity',
'NaN',
'{}',
'{valueOf: function(){return 42}}',
'{toString: function(){return "56"}}',
];
//////
function wrap(tag, s) {
if (s && s.join)
s = s.join('');
return '<' + tag + '>' + String(s) + '</' + tag + '>';
}
function table(head, rows) {
return wrap('table', [
wrap('thead', tr(head)),
wrap('tbody', rows.map(tr))
]);
}
function tr(row) {
return wrap('tr', row.map(function (s) {
return wrap('td', s)
}));
}
function val(n) {
return n === true || Number.isNaN(n) ? wrap('b', n) : String(n);
}
var rows = VALUES.map(function (v) {
var x = eval('(' + v + ')');
return [v].concat(EXPRS.map(function (e) {
return val(eval(e))
}));
});
document.body.innerHTML = table(["x"].concat(EXPRS), rows);
table { border-collapse: collapse }
tr:nth-child(odd) { background: #fafafa }
td { border: 1px solid #e0e0e0; padding: 5px; font: 12px monospace }
td:not(:first-child) { text-align: right }
thead td { background: #3663AE; color: white }
b { color: red }
The table in thg435's answer I believe is comprehensive, however we can summarize with the following patterns:
true
to 1, but "true"
to NaN
. parseInt
is more liberal for strings that are not pure digits. parseInt('123abc') === 123
, whereas +
reports NaN
. Number
will accept valid decimal numbers, whereas parseInt
merely drops everything past the decimal. Thus parseInt
mimics C behavior, but is perhaps not ideal for evaluating user input. parseInt
, being a badly designed parser, accepts octal and hexadecimal input. Unary plus only takes hexademical. Falsy values convert to Number
following what would make sense in C: null
and false
are both zero. ""
going to 0 doesn't quite follow this convention but makes enough sense to me.
Therefore I think if you are validating user input, unary plus has correct behavior for everything except it accepts decimals (but in my real life cases I'm more interested in catching email input instead of userId, value omitted entirely, etc.), whereas parseInt is too liberal.
链接地址: http://www.djcxy.com/p/12834.html上一篇: 如何检查一个字符串“StartsWith”是否是另一个字符串?
下一篇: 何时使用哪个