Conversion en int16, int32, int64 - comment savoir lequel choisir?

Question

Je dois souvent convertir une valeur récupérée (généralement sous forme de chaîne), puis la convertir en int. Mais en C # (.Net), vous devez choisir int16, int32 ou int64. Comment savoir lequel choisir quand vous ne savez pas quelle sera la taille de votre nombre récupéré?

Answer 1

Toutes les personnes ici présentes qui ont mentionné que la déclaration d'une sauvegarde Int16 devaient avoir un vote négatif.

La réponse à votre question consiste à utiliser le mot-clé " int " (ou si vous en avez envie, utilisez "Int32").

Cela vous donne une plage allant jusqu'à 2,4 milliards de numéros ... De plus, les processeurs 32 bits gèrent mieux ces ints ... également (et LA RAISON LA PLUS IMPORTANTE ) est que si vous prévoyez de utiliser cet int pour presque n'importe quelle raison ... il faudra probablement qu'il soit un "int". (Int32).

Dans le cadre .Net, 99,999% des champs numériques (qui sont des nombres entiers) sont "ints". (Int32).

Exemple: Array.Length, Process.ID, Windows.Width, Button.Height, etc., etc., etc., 1 million de fois.

EDIT: Je réalise que ma mauvaise humeur va me décourager de voter… mais c’est la bonne réponse.

Answer 2

Je voulais juste ajouter que ... Je me souvenais que, à l'époque de .NET 1.1, le compilateur était optimisé de sorte que les opérations 'int' soient en réalité plus rapides que les opérations sur des octets ou des opérations courtes.

Je crois que cela tient encore aujourd'hui, mais je lance quelques tests maintenant.

EDIT: J'ai une découverte surprise: les opérations d'addition, de soustraction et de multiplication de short retournent effectivement int!

Answer 3

Essayer à plusieurs reprises TryParse () n'a pas de sens, vous avez un champ déjà déclaré. Vous ne pouvez changer d’avis que si vous définissez ce champ de type Object. Pas une bonne idée.

Les données que le champ représente ont une signification physique. C'est un âge, une taille, un compte, etc. Les quantités physiques ont des contraintes réalistes sur leur portée. Choisissez le type int qui peut stocker cette plage. N'essayez pas de réparer un débordement, ce serait un bug.

Answer 4

Contrairement à la réponse la plus courante actuellement, les entiers plus courts (comme Int16 et SByte) prennent souvent moins de place en mémoire que les entiers plus grands (comme Int32 et Int64). Vous pouvez facilement le vérifier en instanciant de grands tableaux sbyte / short / int / long et en utilisant perfmon pour mesurer les tailles de tas gérées. Il est vrai que de nombreux types de CLR élargiront ces entiers pour les optimisations spécifiques au processeur lorsqu’ils effectueront un calcul arithmétique, etc., mais lorsqu’ils sont stockés dans un objet, ils ne prennent que la quantité de mémoire nécessaire.

Donc, vous devez absolument prendre en compte la taille, en particulier si vous travaillez avec une grande liste d’entiers (ou avec une grande liste d’objets contenant des champs d’entiers). Vous devez également tenir compte d'éléments tels que la conformité CLS (qui interdit tout nombre entier non signé dans les membres publics).

Pour des cas simples tels que la conversion d'une chaîne en un entier, je conviens qu'un Int32 (C # int) est généralement le plus sensé et correspond probablement à ce que les autres programmeurs attendent.

Answer 5

Si nous ne parlons que de quelques chiffres, choisir le plus grand ne fera pas une différence notable dans votre utilisation globale du bélier et fonctionnera tout simplement. Si vous parlez de beaucoup de nombres, vous devrez utiliser TryParse () sur eux et trouver le plus petit type int, pour sauvegarder la RAM.

Answer 6

Tous les ordinateurs sont finis. Vous devez définir une limite supérieure en fonction des besoins de vos utilisateurs.

Si vous n'avez vraiment pas de limite supérieure et souhaitez autoriser des valeurs "illimitées", essayez d'ajouter les bibliothèques d'exécution .Net Java à votre projet, ce qui vous permettra d'utiliser la classe java.math.BigInteger - qui effectue des calculs presque -un nombre entier illimité.

Remarque: les bibliothèques Java .Net sont fournies avec DevStudio, mais je ne pense pas qu'elles soient livrées avec Express.