variable - uso de var en c#
Tipo implícito lanzado en C# (8)
Tengo una pregunta sobre la conversión de tipo implícita
¿Por qué esta conversión de tipo implícito funciona en C #? Aprendí que el código implícito generalmente no funciona.
Tengo un ejemplo de código aquí sobre la conversión de tipo implícito
char c = ''a'';
int x = c;
int n = 5;
int answer = n * c;
Console.WriteLine(answer);
ACTUALIZACIÓN: estoy usando esta pregunta como tema de mi blog hoy. Gracias por la gran pregunta. Por favor, vea el blog para futuras adiciones, actualizaciones, comentarios, etc.
No está del todo claro para mí exactamente lo que estás preguntando. Las preguntas "por qué" son difíciles de responder. Pero voy a intentarlo.
Primero, el código que tiene una conversión implícita de char a int (nota: esto no es un "molde implícito", esta es una "conversión implícita") es legal porque la especificación C # establece claramente que hay una conversión implícita de char a int , y el compilador es, a este respecto, una implementación correcta de la especificación.
Ahora bien, puede señalar con sensatez que la pregunta ha sido meticulosamente suplicada. ¿Por qué hay una conversión implícita de char a int? ¿Por qué los diseñadores del lenguaje creen que esta es una regla sensata para agregar al lenguaje?
Bueno, primero, las cosas obvias que evitarían que esto sea una regla del lenguaje no se aplican. Un char se implementa como un entero de 16 bits sin signo que representa un carácter en una codificación UTF-16, por lo que se puede convertir a un ushort sin pérdida de precisión o, para el caso, sin cambio de representación. El tiempo de ejecución simplemente pasa de tratar este patrón de bits como un char a tratar el mismo patrón de bits como un ushort.
Por lo tanto, es posible permitir una conversión de char a ushort. Ahora, solo porque algo sea posible no significa que sea una buena idea. Claramente, los diseñadores del lenguaje pensaron que convertir implícitamente char a ushort era una buena idea, pero convertir implícitamente ushort a char no lo es. (Y como char para ushort es una buena idea, parece razonable que char-to-anything-that-ushort-goes-to también sea razonable, por lo tanto, char to int. Además, espero que esté claro por qué permitir el casting explícito de ushort a char es sensato; su pregunta es acerca de las conversiones implícitas).
Entonces, tenemos dos preguntas relacionadas aquí: Primero, ¿por qué es una mala idea permitir conversiones implícitas de ushort / short / byte / sbyte a char? y segundo, ¿por qué es una buena idea permitir conversiones implícitas de char a ushort?
A diferencia de usted, tengo a mi disposición las notas originales del equipo de diseño de idiomas. A través de ellos, descubrimos algunos hechos interesantes.
La primera pregunta se trata en las notas del 14 de abril de 1999, donde surge la pregunta de si debería ser legal convertir de byte a char. En la versión original previa a la publicación de C #, esto fue legal por un breve tiempo. He editado ligeramente las notas para dejarlas en claro sin una comprensión de los nombres en código de Microsoft previos a la versión de 1999. También he añadido énfasis en puntos importantes:
[El comité de diseño del idioma] ha elegido proporcionar una conversión implícita de bytes a caracteres, ya que el dominio de uno está completamente contenido por el otro. En este momento, sin embargo, [la biblioteca de tiempo de ejecución] solo proporciona métodos de escritura que toman caracteres y caracteres, lo que significa que los bytes se imprimen como caracteres ya que ese es el mejor método. Podemos resolver esto proporcionando más métodos en la clase Writer o eliminando la conversión implícita.
Hay un argumento sobre por qué lo último es lo correcto. Después de todo, los bytes realmente no son personajes . Es cierto que puede haber un mapeo útil de bytes a caracteres, pero en última instancia, 23 no denota lo mismo que el carácter con el valor ascii 23, de la misma manera que 23B denota lo mismo que 23L. Pedir a los autores de la biblioteca que proporcionen este método adicional simplemente por la forma en que funciona una peculiaridad en nuestro sistema de tipos parece bastante débil. Entonces, sugiero que hagamos explícita la conversión de byte a char.
Las notas luego concluyen con la decisión de que byte-to-char debe ser una conversión explícita, y ente-literal-in-range-of-char también debe ser una conversión explícita.
Tenga en cuenta que las notas de diseño del idioma no indican por qué ushort-to-char también se volvió ilegal al mismo tiempo, pero puede ver que se aplica la misma lógica. Cuando se llama a un método sobrecargado como M (int) y M (char), cuando le pasa un ushort, es bueno que quiera tratar el ushort como un número, no como un personaje. Y un ushort no es una representación de caracteres de la misma manera que un ushort es una representación numérica, por lo que parece razonable hacer que esa conversión también sea ilegal.
La decisión de hacer que Char vaya a ushort se hizo el 17 de septiembre de 1999; las notas de diseño de ese día sobre este tema simplemente afirman "char to ushort también es una conversión legal implícita", y eso es todo. Ninguna otra exposición de lo que estaba sucediendo en las cabezas del diseñador del lenguaje ese día es evidente en las notas.
Sin embargo, podemos hacer conjeturas sobre por qué implícita char-to-ushort fue considerada una buena idea. La idea clave aquí es que la conversión de número a personaje es una conversión "posiblemente dudosa". Es tomar algo que NO SABES tiene la intención de ser un personaje y elegir tratarlo como tal. Parece el tipo de cosa que desea llamar que está haciendo explícitamente, en lugar de permitirlo accidentalmente. Pero el reverso es mucho menos fiable. Existe una larga tradición en la programación C de tratar caracteres como enteros: para obtener sus valores subyacentes o para hacer matemáticas sobre ellos.
En resumen: parece razonable que usar un número como personaje sea un accidente y un error, pero también parece razonable que usar un personaje como número sea deliberado y deseable. Esta asimetría se refleja, por lo tanto, en las reglas del lenguaje.
Eso responde tu pregunta?
De la especificación de C #
6.1.2 Conversiones numéricas implícitas Las conversiones numéricas implícitas son:
• De sbyte a short, int, long, float, double o decimal.
• De byte a short, ushort, int, uint, long, ulong, float, double o decimal.
• De corto a int, largo, flotante, doble o decimal.
• Desde ushort a int, uint, long, ulong, float, double o decimal.
• Desde int a long, float, double o decimal.
• Desde uint a long, ulong, float, double o decimal.
• De largo a flotante, doble o decimal.
• De ulong a flotante, doble o decimal.
• Desde char a ushort, int, uint, long, ulong, float, double o decimal.
• De flotación a doble.
Las conversiones de int, uint, long o ulong para flotar y de long o ulong a double pueden causar una pérdida de precisión, pero nunca causarán una pérdida de magnitud. Las otras conversiones numéricas implícitas nunca pierden ninguna información. No hay conversiones implícitas al tipo de caracteres, por lo que los valores de los otros tipos integrales no se convierten automáticamente al tipo de caracteres.
Desde la página de MSDN sobre el char ( char (C # Reference) :
Un char se puede convertir implícitamente a ushort, int, uint, long, ulong, float, double o decimal. Sin embargo, no hay conversiones implícitas de otros tipos al tipo de caracteres.
Es porque han implementado un método implícito de char a todos esos tipos. Ahora, si preguntas por qué los implementaron, realmente no estoy seguro, sin duda para ayudar a trabajar con la representación ASCII de caracteres o algo así.
El char se envía implícitamente a su valor numérico Unicode, que es un número entero.
Funciona porque cada personaje se maneja internamente como un número, por lo tanto, el elenco está implícito.
La conversión implícita de tipo char a número no tiene sentido, en mi opinión, porque ocurre una pérdida de información. Puedes verlo desde este ejemplo:
string ab = "ab";
char a = ab[0];
char b = ab[1];
var d = a + b; //195
Hemos puesto toda la información de la cadena en caracteres. Si por casualidad solo se conserva la información de d, todo lo que nos queda es un número que no tiene sentido en este contexto y no puede utilizarse para recuperar la información proporcionada previamente. Por lo tanto, la forma más útil de ir sería convertir implícitamente la "suma" de caracteres en una cadena.
La idea básica es que las conversiones que conducen a una posible pérdida de datos pueden ser implícitas, mientras que las conversiones, que pueden conducir a la pérdida de datos, deben ser explícitas (utilizando, por ejemplo, un operador de conversión).
Así que implícitamente la conversión de char a int funcionará en C #.
[edit] Como otros señalaron, un char es un número de 16 bits en C #, por lo que esta conversión es solo de un entero de 16 bits a un entero de 32 bits, que es posible sin pérdida de datos. [/ edit]
C # admite conversiones implícitas, la parte "normalmente no funciona" probablemente provenga de algún otro lenguaje, probablemente C ++, donde algunas implementaciones de string gloriosas proporcionaron conversiones implícitas a diversos tipos de punteros, creando algunos errores gigantescos en las aplicaciones.
Cuando, en cualquier idioma, proporciona conversiones de tipo, también debe realizar conversiones explícitas por defecto y solo proporcionar conversiones implícitas para casos especiales.