Quelles sont les différences entre cette ligne:

var a = parseInt("1", 10); // a === 1

et cette ligne

var a = +"1"; // a === 1

Ce test jsperf montre que l'opérateur unaire est beaucoup plus rapide dans la version actuelle de chrome, en supposant que ce soit pour node.js !?

Si j'essaie de convertir des chaînes qui ne sont pas des nombres, les deux renvoient NaN:

var b = parseInt("test" 10); // b === NaN
var b = +"test"; // b === NaN

Alors, quand devrais-je préférer utiliser parseIntle plus unaire (en particulier dans node.js) ???

edit : et quelle est la différence avec l'opérateur double tilde ~~?

Veuillez consulter cette réponse pour un ensemble plus complet de cas

Eh bien, voici quelques différences que je connais:

• Une chaîne vide ""évalue à a 0, tandis que l' parseIntévalue à NaN. IMO, une chaîne vide doit être un NaN.

  +'' === 0;              //true
  isNaN(parseInt('',10)); //true

• L'unaire +agit plus comme parseFloatpuisqu'il accepte également les décimales.

  parseIntd'autre part, arrête l'analyse quand il voit un caractère non numérique, comme le point qui est censé être un point décimal ..

  +'2.3' === 2.3;           //true
  parseInt('2.3',10) === 2; //true

• parseIntet parseFloatanalyse et construit la chaîne de gauche à droite . S'ils voient un caractère invalide, il renvoie ce qui a été analysé (le cas échéant) comme un nombre, et NaNsi aucun n'a été analysé comme un nombre.

  L'unaire, +en revanche, retournera NaNsi la chaîne entière n'est pas convertible en nombre.

  parseInt('2a',10) === 2; //true
  parseFloat('2a') === 2;  //true
  isNan(+'2a');            //true

• Comme vu dans le commentaire de @Alex K. , parseIntet parseFloatanalysera par caractère. Cela signifie que les notations hexadécimales et exposantes échoueront car les xet esont traités comme des composants non numériques (au moins sur base10).

  +Cependant, l' unaire les convertira correctement.

  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.

La table de conversion ultime quel que soit en nombre:

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',
    'undefined',
    '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 }

Je pense que le tableau de la réponse de thg435 est complet, mais nous pouvons le résumer avec les modèles suivants:

• Unary plus ne traite pas toutes les fausses valeurs de la même manière, mais elles sont toutes fausses.
• Unaire plus envoie trueà 1, mais "true"à NaN.
• En revanche, parseIntest plus libéral pour les chaînes qui ne sont pas de purs chiffres. parseInt('123abc') === 123, tandis que les +rapports NaN.
• Numberacceptera des nombres décimaux valides, alors parseIntque tout simplement abandonne tout au-delà de la décimale. Ainsi parseIntimite le comportement C, mais n'est peut-être pas idéal pour évaluer les entrées de l'utilisateur.
• Les deux coupent les espaces dans les chaînes.
• parseInt, étant un analyseur mal conçu , accepte les entrées octales et hexadécimales. Unary plus ne prend que hexadécimal.

Les valeurs fausses sont converties en Numbersuivant ce qui aurait du sens dans C: nullet falsesont toutes les deux nulles. ""aller à 0 ne suit pas tout à fait cette convention mais me semble assez logique.

Par conséquent, je pense que si vous validez l'entrée de l'utilisateur, unary plus a un comportement correct pour tout sauf qu'il accepte les décimales (mais dans mes cas réels, je suis plus intéressé par la capture de l'entrée d'e-mail au lieu de userId, valeur entièrement omise, etc.), alors que parseInt est trop libéral.

Attention, parseInt est plus rapide que l'opérateur unaire + dans Node.JS, il est faux que + ou | 0 sont plus rapides, ils ne le sont que pour les éléments NaN.

Regarde ça:

var arg=process.argv[2];

rpt=20000;
mrc=1000;

a=[];
b=1024*1024*1024*1024;
for (var i=0;i<rpt;i++)
 a[i]=Math.floor(Math.random()*b)+' ';

t0=Date.now();
if ((arg==1)||(arg===undefined))
 for (var j=0;j<mrc;j++) for (var i=0;i<rpt;i++) {
  c=a[i]-0;
 }
t1=Date.now();
if ((arg==2)||(arg===undefined)) {
 for (var j=0;j<mrc;j++) for (var i=0;i<rpt;i++) {
  d=a[i]|0;
 }
}
t2=Date.now();
if ((arg==3)||(arg===undefined)) {
 for (var j=0;j<mrc;j++) for (var i=0;i<rpt;i++) {
  e=parseInt(a[i]);
 }
}
t3=Date.now();
 if ((arg==3)||(arg===undefined)) {
 for (var j=0;j<mrc;j++) for (var i=0;i<rpt;i++) {
  f=+a[i];
 }
}
t4=Date.now();

console.log(a[i-1],c,d,e,f);
console.log('Eseguiti: '+rpt*mrc+' cicli');
console.log('parseInt '+(t3-t2));
console.log('|0 '+(t2-t1));
console.log('-0 '+(t1-t0));
console.log('+ '+(t4-t3));

Pensez également aux performances . J'ai été surpris que cela parseIntbat unaire plus sur iOS :) Ceci n'est utile que pour les applications Web avec une forte consommation de processeur. En règle générale, je suggérerais à JS opt-guys de considérer n'importe quel opérateur JS plutôt qu'un autre du point de vue des performances mobiles de nos jours.

Alors, passez d'abord au mobile ;)