J'ai une question sur la conversion de type implicite
Pourquoi cette conversion de type implicite fonctionne-t-elle en C #? J'ai appris que le code implicite ne fonctionne généralement pas.
J'ai un exemple de code ici sur la conversion de type implicite
char c = 'a';
int x = c;
int n = 5;
int answer = n * c;
Console.WriteLine(answer);
Mise à JOUR: je suis à l'aide de cette question que le sujet de mon blog aujourd'hui. Merci pour la grande question. Consultez le blog pour les futurs ajouts, mises à jour, des commentaires, et ainsi de suite.
Il n'est pas tout à fait clair pour moi qu'est-ce exactement que vous vous posez. Le "pourquoi" des questions difficiles à répondre. Mais je vais prendre une chance.
Tout d'abord, le code qui a une conversion implicite de char en int (note: ce n'est pas un "cast implicite", c'est une "conversion implicite") est légal, car la spécification C# indique clairement qu'il y a une conversion implicite de char en int, et le compilateur est, à cet égard, une mise en œuvre correcte de la spécification.
Maintenant, vous pourriez raisonnablement que la question a été longuement supplié. Pourquoi il y a une conversion implicite de char en int? Pourquoi les concepteurs de la langue croire que c'était une règle sensée à ajouter à la langue?
Bien, tout d'abord, les choses évidentes qui permettrait d' éviter d'être une règle de la langue ne s'appliquent pas. Un char est mis en œuvre comme un entier non signé de 16 bits nombre entier qui représente un personnage dans un encodage UTF-16, de sorte qu'il peut être converti en ushort sans perte de précision, ou, d'ailleurs, sans changement de représentation. L'exécution va tout simplement de traiter cette séquence de bits comme un char pour le traitement de la même séquence de bits en tant que ushort.
Il est donc possible pour permettre une conversion de char à ushort. Maintenant, juste parce que quelque chose est possible ne signifie pas que c'est une bonne idée. Clairement les concepteurs du langage de la pensée qui, implicitement, la conversion de char à ushort était une bonne idée, mais implicitement la conversion ushort de char n'est pas. (Et depuis char à ushort est une bonne idée, il semble raisonnable de char-à-rien-que-ushort à est également raisonnable, par conséquent, char, int. Aussi, j'espère que c'est clair pourquoi le fait de permettre explicite de la coulée de ushort à char, c'est raisonnable; votre question est à propos des conversions implicites.)
Nous avons en fait deux questions: tout d'Abord, pourquoi est-ce une mauvaise idée de permettre les conversions implicites de ushort/court/byte/sbyte de char? et la deuxième, pourquoi est-ce une bonne idée de permettre les conversions implicites de char à ushort?
Contrairement à vous, j'ai l'original des notes à partir de la langue de conception de l'équipe à ma disposition. Creuser par le biais de ceux-ci, nous découvrons quelques faits intéressants.
La première question est abordée dans la note du 14 avril 1999, où la question de savoir s'il devrait être légal pour convertir à partir de l'octet de char se pose. À l'origine, une pré-version de C#, il est légal pour un bref moment. J'ai légèrement modifié les notes afin de les rendre claires, sans une compréhension de 1999 de l'ère pré-version de Microsoft noms de code. J'ai aussi ajouté l'accent sur des points importants:
[La langue de conception de] a choisi de fournir une conversion implicite d'octets pour les caractères, étant donné que le domaine de l'un est entièrement contenue par les autres. Maintenant, cependant, [le runtime bibliothèque] seulement de fournir des méthodes d'Écriture qui prennent des chars et des services de renseignements, ce qui signifie que les octets imprimer des caractères depuis que finit par être le meilleur la méthode. Nous pouvons résoudre ce soit par fournir des méthodes plus sur l'Auteur classe ou par suppression de l'implicite la conversion.
Il y a un argument pour expliquer pourquoi l' ce dernier est la bonne chose à faire. Après tout, les octets ne sont pas vraiment des personnages. Vrai, il y a peut être un utile cartographie d'octets pour les caractères, mais en fin de compte, 23 ne désigne pas l' même chose que le caractère ascii valeur 23, de la même manière que 23B désigne la même chose que 23L. Demander [la bibliothèque des auteurs] de fournir cette méthode supplémentaire tout simplement parce que de comment un caprice dans notre type de système fonctionne semble plutôt faible. Je voudrais donc nous suggèrent de faire la conversion à partir de l'octet de char explicite.
Les notes de conclure avec la décision de l'octet-à-char devrait être une conversion explicite, et entier littéral-de-gamme-de-char devrait également être une conversion explicite.
Notez que la langue des design notes n'appelez pas pourquoi ushort-à-char a également été rendue illégale dans le même temps, mais vous pouvez voir que la même logique s'applique. Lors de l'appel d'une méthode surchargée comme M(int) et M(char), lorsque vous passez un ushort, les chances sont bonnes que vous voulez traiter la ushort comme un nombre, non pas comme un personnage. Et un ushort n'est PAS un personnage de la représentation de la même manière qu'un ushort est une représentation numérique, il semble donc raisonnable de faire cette conversion illégal.
La décision de faire un char aller à ushort a été faite le 17 septembre 1999; le design notes à partir de ce jour sur ce sujet simplement de l'état "char à ushort est également la conversion implicite", et c'est tout. Aucune autre exposition de ce qui se passait dans la langue du designer chefs de la journée est évident dans les notes.
Cependant, nous pouvons faire des suppositions éclairées pourquoi implicite char-à-ushort a été considéré comme une bonne idée. L'idée clé ici est que la conversion de nombre de caractère est un "peut-être douteux" de conversion. C'est quelque chose que vous ne SAVEZ pas à qui est destiné à être un personnage, et en choisissant de le traiter comme un. Cela semble être le genre de chose que vous voulez l'appeler que vous faites de façon explicite, plutôt que de permettre accidentellement il. Mais l'inverse est beaucoup moins douteux. Il y a une longue tradition dans la programmation en C de traiter les caractères comme des nombres entiers -- pour obtenir leurs valeurs sous-jacentes, ou pour faire des mathématiques sur eux.
En bref: il semble raisonnable que l'utilisation d'un nombre comme un personnage pourrait être un accident et un bug, mais il semble également raisonnable que l'utilisation d'un personnage, comme un certain nombre est délibéré et souhaitable. Cette asymétrie est donc reflétées dans les règles de la langue.
Ne fait que répondre à votre question?
L'idée de base est que les conversions entraînant la perte de données peut être implicite, tandis que les conversions, ce qui peut conduire à la perte de données doivent être explicites (en utilisant, par exemple, un opérateur de cast).
Donc, implicitement, de la conversion de char de int travaillera en C#.
[edit]Comme d'autres l'ont souligné, une char est un 16 bits en C#, de sorte que cette conversion est seulement à partir d'un entier 16 bits d'un entier de 32 bits, ce qui est possible sans perte de données.[/edit]
C# prend en charge les conversions implicites, la partie "l'habitude de ne pas travailler" est probablement en provenance d'une autre langue, probablement en C++, où quelques glorieux string implémentations fournies conversions implicites à divers pointeur-types, créant une gigantesque bugs dans les applications.
Quand vous, dans quelque langue que ce soit, de fournir de type conversions, vous devez par défaut pour les conversions explicites par défaut, et seulement de fournir des conversions implicites pour des cas particuliers.
À Partir De C# Spécification
6.1.2 Implicite conversions numériques L'implicite conversions numériques sont:
• À partir de sbyte de short, int, long, float, double, ou décimal.
• À partir de l'octet de short, ushort, int, uint, long, ulong, float, double, ou décimal.
• Courts de type int, long, float, double ou décimale.
• À partir de ushort int, uint, long, ulong, float, double, ou décimal.
• À partir de int, long, float, double, ou décimal.
• À partir de uint à la longue, ulong, float, double ou décimale.
• De temps pour float, double, ou décimal.
• À partir de ulong de float, double, ou décimal.
• À partir de char à ushort, int, uint, long, ulong, float, double, ou décimal.
• À partir de float en double.
Les Conversions de type int, uint, long, ou ulong de flotter et de long ou ulong à double peut entraîner une perte de de précision, mais ne sera jamais la cause d'une perte de grandeur. L'autre implicite conversions numériques ne perdrez jamais de l'information. Il n'y a pas implicite les conversions vers le type char, donc les valeurs de l'autre partie intégrante des types de convertit pas automatiquement à la char type.
À partir de la page MSDN sur le char (char (Référence C#) :
Un char peut être implicitement converti à ushort, int, uint, long, ulong, float, double, ou décimal. Cependant, il n'existe pas de conversions implicites à partir d'autres types pour le type char.
C'est parce qu'ils ont mis en œuvre une méthode implicite de char à tous ces types. Maintenant, si vous vous demandez pourquoi ils ont mis en place, je ne suis vraiment pas sûr, bien sûr pour l'aider à travailler avec la représentation ASCII des caractères ou quelque chose comme ça.
Edit: la diffusion entraînera la perte de données. ici omble chevalier est de 16 bits et int est de 32 bits. de sorte que la distribution se produira sans perte de données.
Exemple concret: nous pouvons placer un petit navire dans un grand navire, mais pas l’inverse sans aide extérieure.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
