Double.TryParse ou Convertir.ToDouble - ce qui est plus rapide et plus sûr?

Mon application lit un fichier Excel à l'aide de VSTO et ajoute la lecture des données à un StringDictionary. Il ajoute que les données sont des nombres avec quelques chiffres (1000 1000,2 1000,34 - virgule est un séparateur dans les normes russes).

Ce qui est le mieux pour vérifier si la chaîne est un nombre approprié?

object data, string key; //data had read

try
{
  Convert.ToDouble(regionData, CultureInfo.CurrentCulture);
  dic.Add(key, regionData.ToString());
}
catch (InvalidCastException)
{
  //is not a number
}

ou

double d;
string str = data.ToString();
if (Double.TryParse(str, out d)) //if done, then is a number
{
  dic.Add(key, str);
}

- Je utiliser StringDictionary au lieu de Dictionary<string, double> à cause de la suite de l'analyse de l'algorithme de questions.

Mes questions: Qui est le plus rapide? Ce qui est plus sûr?

Et est-il mieux d'appeler Convert.ToDouble(object) ou Convert.ToDouble(string) ?

  • Pour info, double.TryParse est la même chose que try { résultat = double.Parse(s); return true; } catch { return false; }. Convertir est essentiellement un wrapper pour les deux avec un tas de surcharges. Il ne fait aucune différence comment vous le faites. Mais comme Jon l'a fait observer, réfléchir à la façon de gérer la mauvaise entrée.
  • Double.TryParse n'est pas le même que le double.Analyser enveloppé dans un try..catch. La sémantique est la même, mais le chemin de code est différent. TryParse vérifie d'abord que la chaîne est un nombre à l'aide d'un Numéro interne.TryStringToNumber, tandis que d'Analyser suppose que c'est déjà un numéro/double.
InformationsquelleAutor abatishchev | 2009-02-25
  1. 128

    J'ai fait une rapide non-scientifique de test en mode Release. J'ai utilisé deux entrées: "2.34523" et "badinput" dans les deux méthodes et répété de 1 000 000 de fois.

    D'entrée valides:

    Double.TryParse = 646ms
Convert.ToDouble = 662 ms

    Pas grand chose de différent, comme prévu. Pour toutes fins utiles, pour les entrées valides, ce sont les mêmes.

    D'entrée non valide:

    Double.TryParse = 612ms
Convert.ToDouble = ..

    Bien.. il était en cours d'exécution pendant une longue période. J'ai rediffusé l'intégralité de la chose à l'aide de 1 000 itérations et Convert.ToDouble avec une mauvaise entrée a pris 8,3 secondes. En moyenne, il faudrait plus de 2 heures. Je n'ai pas de soins de base est le test, dans le cas d'entrée non valide, Convert.ToDoubles'exception de sensibilisation va ruiner votre performance.

    Donc, voici une autre voter pour TryParse avec quelques chiffres à l'appui.

    • Outre les choses mentionnées ci-dessus, j'ai juste trouvé que Convertir.ToDouble() lève une exception avec les nombres en notation scientifique. Considérez ceci: double toDouble = Convert.ToDouble((-1/30000).ToString()); // échoue double dblParse = Double.Parse((-1/30000).ToString()); // fonctionne très bien
    InformationsquelleAutor Szymon Rozga
  2. 46

    Pour commencer, je voudrais utiliser double.Parse plutôt que Convert.ToDouble en premier lieu.

    Si vous devez utiliser Parse ou TryParse: pouvez-vous aller de l'avant si il y a de mauvaises données d'entrée, ou est-ce vraiment un état exceptionnel? Si c'est exceptionnel, l'utilisation Parse et laisser exploser si l'entrée est mauvais. Si c'est normal et peut être correctement traitée, l'utilisation TryParse.

    • Jon,Pouvez-vous expliquer pourquoi vous préférez double.Analyser sur Convertir.ToDouble?
    • J'ai rarement envie null être converti en 0 (qui Convertir.ToDouble n'), en gros. Il est aussi généralement plus souples. J'ai juste tendance à aller pour les méthodes spécifiques...
    InformationsquelleAutor Jon Skeet
  3. 8

    L' .NET Framework de conception de lignes directrices recommandent à l'aide de l'essai de méthodes. En évitant les exceptions est généralement une bonne idée.

    Convert.ToDouble(object) fera ((IConvertible) object).ToDouble(null);

    Qui feront appel Convert.ToDouble(string, null)

    De sorte qu'il est plus rapide d'appeler la chaîne de version.

    Cependant, la version de chaîne ne fonctionne tout simplement ceci:

    if (value == null)
{
    return 0.0;
}
return double.Parse(value, NumberStyles.Float | NumberStyles.AllowThousands, provider);

    De sorte qu'il est plus rapide de faire le double.Parse directement.

    InformationsquelleAutor Jeff Moser
  4. 7

    Si vous n'allez pas être de la manipulation de l'exception aller avec TryParse. TryParse est plus rapide car il n'a pas à traiter l'ensemble de la trace de pile d'exception.

    InformationsquelleAutor Aaron Palmer
  5. 7

    De manière générale, j'essaie d'éviter les Convert classe (ce qui signifie: je ne l'utilise pas) parce que je trouve qu'il est très déroutant: le code donne aussi quelques conseils sur ce qu'il se passe exactement ici depuis Convert permet à beaucoup de point de vue sémantique très différentes conversions à se produire avec le même code. Cela le rend difficile à contrôler pour le programmeur de ce qui se passe exactement.

    Mon conseil est donc de ne jamais utiliser cette classe. Ce n'est pas vraiment nécessaire (sauf pour les binaires de mise en forme d'un nombre, parce que la normale ToString méthode de nombre de classes n'offre pas une méthode appropriée pour ce faire).

    InformationsquelleAutor Konrad Rudolph
  6. 7

    Sauf si vous êtes certain à 100% de vos entrées, ce qui est rarement le cas, vous devriez utiliser des Doubles.TryParse.

    Convert.ToDouble will throw an exception on non-numbers
Double.Parse will throw an exception on non-numbers or null
Double.TryParse will return false or 0 on any of the above without generating an exception.

    La vitesse de l'analyse devient secondaire quand on lance une exception, car il n'est pas beaucoup plus lent que d'une exception.

    InformationsquelleAutor Chase
  7. 3

    Beaucoup de haine pour la classe Convert ici... Juste pour équilibrer un peu, il y a un avantage pour les Convertir - si vous êtes à la remise d'un objet,

    Convert.ToDouble(o);

    pouvez simplement retourner la valeur facilement si o est déjà un Double (ou un int ou quoi que ce soit facilement moulage).

    En Utilisant Le Double.Analyser ou Double.TryParse est idéal si vous l'avez déjà dans une chaîne de caractères, mais

    Double.Parse(o.ToString());

    a aller faire la chaîne pour être analysé tout d'abord et en fonction de votre niveau d'entrée qui pourrait être plus coûteux.

    • +1: je comprends votre point de vue, l'analyse en boîte numéros/cordes avec le numéro à l'intérieur d'un Système.L'objet est assez facile, au lieu d'un massif de vérification de type. Mais, fondamentalement, je suis d'accord avec les autres réponses: Convert.ToSomething() est tellement cher plutôt que d'Analyser/TryParse, en particulier dans un contexte itération
    • Pour moi, Convertir.ToDouble(o) est un peu facile outs si ce qui est dans la boîte est déjà un certain nombre, mais le véritable assassin pour Convertir, c'est qu'il n'a pas .TryToDouble(o, d); compte tenu de la gamme de prix d'exceptions (degré de confiance de vous - ou pas - des entrées), qui est la plus grosse dépense supplémentaire de Convertir.
    InformationsquelleAutor user1664043
  8. 2

    Double.TryParse de l'OMI.

    Il est plus facile pour vous de gérer, Vous saurez exactement où l'erreur s'est produite.

    Ensuite, vous pouvez traiter avec elle, comment vous voyez l'ajustement si elle retourne false (j'.e ne peut pas convertir).

    InformationsquelleAutor Damien
  9. 2

    J'ai toujours préféré à l'aide de la TryParse() méthodes parce qu'il va cracher le dos de la réussite ou de l'échec de convertir sans avoir à se soucier des exceptions.

    InformationsquelleAutor TheTXI
  10. 1

    Personnellement, je trouve le TryParse méthode plus facile à lire, qui un que vous voulez utiliser dépend de votre cas d'utilisation: si des erreurs peuvent être gérées localement, vous vous attendez à des erreurs et un bool de TryParse est bon, autre chose que vous voulez laisser les exceptions à la mouche.

    J'attendrais la TryParse pour être plus rapide, car elle évite la surcharge de la gestion des exceptions. Mais l'utilisation d'un outil de référence, comme Jon Skeet est MiniBench à comparer les différentes possibilités.

    • Retour sur cette réponse: Si les questions demande ce qui est plus rapide et plus sûr, la réponse ne doit pas commencer par: "Personnellement" et inclure deviner comme: "je m'attends...". C'est juste de la réflexion personnelle et de commentaire, pas une bonne réponse.
    InformationsquelleAutor David Schmitt
  11. 1

    C'est intéressant à une vieille question. Je suis en ajoutant une réponse parce que personne ne l'a remarqué un couple de choses avec la question d'origine.

    Qui est plus rapide: Convertir.ToDouble ou Double.TryParse?
    Ce qui est plus sûr: Convertir.ToDouble ou Double.TryParse?

    Je vais répondre à ces deux questions (je vais mettre à jour la réponse plus tard), dans le détail, mais d'abord:

    Pour la sécurité, la chose chaque programmeur manqué dans cette question est de la ligne (l'emphase est mienne):

    Il ajoute que les données sont des nombres avec quelques chiffres (1000 1000,2 1000,34 - virgule est un séparateur dans les normes russes).

    Suivie par cet exemple de code:

    Convert.ToDouble(regionData, CultureInfo.CurrentCulture);

    Ce qui est intéressant ici est que si les feuilles de calcul sont en russe format de nombre, mais Excel n'a pas été correctement saisis les champs de cellule, quelle est la bonne interprétation des valeurs en provenance d'Excel?

    Ici est une autre chose intéressante à propos de ces deux exemples, concernant la vitesse:

    catch (InvalidCastException)
{
    //is not a number
}

    Cela est susceptible de générer des MSIL qui ressemble à ceci:

    catch [mscorlib]System.InvalidCastException 
{
  IL_0023:  stloc.0
  IL_0024:  nop
  IL_0025:  ldloc.0
  IL_0026:  nop
  IL_002b:  nop
  IL_002c:  nop
  IL_002d:  leave.s    IL_002f
}  //end handler
IL_002f: nop
IL_0030: return

    Dans ce sens, on peut sans doute comparer le nombre total d'instructions MSIL réalisée par chaque programme - plus sur cela plus tard que j'ai mise à jour de ce post.

    Je crois que le code doit être Correcte, Claire et Rapide... Dans cet ordre!

    InformationsquelleAutor John Zabroski