Llevamos ya varias entregas de la serie C# bizarro, donde, como sabéis, ponemos a prueba nuestros conocimientos de C# llevando al extremo el uso de algunas de sus características, lo que de paso nos ayuda a conocer mejor aún el lenguaje.
Hoy vamos a proponer un nuevo reto, mostrando un comportamiento que quizás muchos conozcáis, pero seguro que otros nunca habéis tenido ocasión de verlo. A ver qué tal se os da ;)
Observad atentamente esta sencilla aplicación de consola:
int i = 1;
int accum = 0;
while (i <= 5)
{
accum += i;
Debug.WriteLine($"Adding {i++}, Accumulated = {accum}");
}
Console.WriteLine($"Total: {accum}");
A la vista del código, las preguntas son dos: ¿Qué resultado obtenemos al ejecutar la aplicación? ¿Será siempre así?
Obviamente, tiene algo de truco, pero si lo pensáis un poco seguro que podéis responder a las preguntas. Y si no, pulsad aquí para ver la solución; 👇👇
En principio, lo lógico es pensar que deberíamos ver en el canal de depuración (la ventana Output>Debug en Visual Studio) el valor actual y el total acumulado en cada iteración, lo que nos permite ir siguiendo en detalle el funcionamiento interno:
Adding 1, Accumulated = 1
Adding 2, Accumulated = 3
Adding 3, Accumulated = 6
Adding 4, Accumulated = 10
Adding 5, Accumulated = 15
Finalmente, se mostrará por consola el valor definitivo:
Total: 15
Esto será justamente lo que obtengamos si copiamos el código en Visual Studio y lo ejecutamos pulsando F5 o el botón correspondiente del IDE. Hasta ahí, perfecto ;)
Sin embargo, este código tiene una trampa oculta. Si desde Visual Studio cambiamos el modo de compilación a "Release" y lo lanzamos, o bien si lanzamos directamente el ejecutable que encontraremos en la carpeta bin/Release/net8.0
(o la versión de .NET que uses, da igual), veremos que la aplicación no se detiene nunca (?!)
El motivo de este extraño comportamiento lo explicamos hace ya bastantes años por aquí, en el post métodos condicionales en C#.
Estos métodos, presentes desde las primeras versiones de .NET (pre-Core), se decoran con el atributo [Conditional]
para hacer que éstos y todas las referencias a los mismos sean eliminadas del ensamblado resultante de la compilación si no existe una constante de compilación determinada.
De hecho, si acudimos al código fuente de la clase estática Debug
, veremos que su método WriteLine()
está definido de la siguiente manera:
public static partial class Debug
{
...
[Conditional("DEBUG")]
public static void WriteLine(string? message)
=> s_provider.WriteLine(message);
}
Cuando compilamos en modo depuración, la constante DEBUG
estará definida, por lo que este método podrá ser invocado con normalidad y todo funcionará bien. Sin embargo, si compilamos en Release o cualquier otra configuración que no incluya la constante, este método desaparecerá del ensamblado, junto con las referencias que lo utilicen.
Es decir, si usamos el modo Release, el código que hemos escrito antes quedará tras la compilación como el siguiente:
int i = 1;
int accum = 0;
while (i <= 5)
{
accum += i;
// La siguiente llamada será eliminada en compilación:
// Debug.WriteLine($"Adding {i++}, Accumulated = {accum}");
}
Console.WriteLine($"Total: {accum}");
Fijaos que, al eliminar la llamada, con ella desaparecerá también la expresión de autoincremento del índice del bucle i++
, por lo que nunca se alcanzará la condición de salida y quedará iterando de forma indefinida.
Bonito, ¿eh? ;)
Publicado en Variable not found.
Ya he comentado alguna vez que el hecho de trabajar a diario con C# no implica que conozcamos todas sus funcionalidades, detalles, trampas y recovecos. Después de muchos años, yo sigo encontrándome sorpresas bastante a menudo.
Hace poco, andaba haciendo algunas pruebas y llegué a un código como el siguiente:
var a = 1;
var (b, c) = 4;
var (d, e, f) = 9;
Console.WriteLine(a + b + c + d + e + f ); // Muestra por consola "14"
Así al vistazo, diréis que el código no compila tal cual, pero la pregunta es: ¿sería posible que compilara y, además, mostrara la salida que pretendemos sin tocar una sola línea de las que vemos ahí?
Si lo pensáis un poco seguro que podéis responder a las preguntas. Y si no, pulsad aquí para ver la solución 👇👇
Pues en efecto, el código tal y como está no compila, así que debemos pasar a la siguiente parte de la pregunta: qué podemos hacer para que compile y, además, muestre por consola el valor que buscamos, sin tocar ni una coma de esas cuatro líneas de código propuesto como punto de partida.
Si nos fijamos bien, la primera línea es una asignación normal, pero en la segunda y tercera línea estamos asignando valores a variables usando sintaxis propia de tuplas. En el fondo, ambas líneas son iguales, y fallan en compilación porque no podemos asignar un entero a un tupla. ¿O quizás sí?
Si recordáis, hace mucho tiempo hablamos por aquí de la deconstrucción de clases, un interesante mecanismo que, al más puro estilo de cheff sofisticado, permitía deconstruir o descomponer objetos en tuplas, simplemente implementando el método Deconstruct()
.
Pues bien, resulta que este método Deconstruct()
puede implementarse de forma externa al tipo que va a ser deconstruido mediante extension methods. Seguro que ya empezáis a ver por dónde van los tiros... 😉 En efecto, podríamos implementar el método extensor Deconstruct()
sobre el tipo int
e introducir en él la lógica que nos interese.
Una posible implementación sería la siguiente, en la que tenemos sobrecargas de Deconstruct()
para dos y tres parámetros de salida, entre los que repartimos equitativamente el valor del entero a deconstruir:
public static class IntegerExtensions
{
public static void Deconstruct(this int i, out int i1, out int i2)
{
(i1, i2) = (i / 2, i / 2);
}
public static void Deconstruct(this int i, out int i1, out int i2, out int i3)
{
(i1, i2, i3) = (i / 3, i / 3, i / 3);
}
}
Si ejecutamos ahora mentalmente el código propuesto, veremos que se cumplen los requisitos iniciales:
var a = 1; // a=1
var (b, c) = 4; // "4" se deconstruye en (2,2). Por tanto: b=c=2
var (d, e, f) = 9; // "9" se deconstruye en (3,3,3). Por tanto, d=e=f=3
Console.WriteLine(a + b + c + d + e + f ); //
1+2+2+3+3+3 -> Muestra "14":
Bonito y maquiavélico uso de tuplas y deconstrucción, ¿verdad? 😉
Aunque muchos de nosotros trabajamos a diario con C#, siempre hay algo nuevo por aprender o formas de utilizar algunas características que nunca se nos habían ocurrido. Siempre.
En un nuevo capítulo de la serie de C# bizarro, hoy os planteo un reto sobre este código:
var sum = (int a, int b) => a + b;
var sub = (int a, int b) => a - b;
var mul = (int a, int b) => a * b;
var result = sum - sub + mul;
Console.WriteLine("Resultado: " + result(3, 2));
¿Compila? Y si es así, ¿qué aparece por consola? ¡No sigáis leyendo! Echad un vistazo al código e intentad averiguarlo antes de ver la solución pulsando aquí :)
Pues sí, este código es totalmente válido y compilará sin problema. Y al ejecutarlo, por consola veremos lo siguiente.
Resultado: 6
En primer lugar el código compila correctamente porque las variables sum
, sub
y mult
, que hemos definido usando expresiones lambda de tipo Func<int, int, int>
, a la postre son simplemente delegados.
Además, los tres delegados tienen la firma idéntica (reciben dos valores int
y retornan un int
), podemos utilizar los operadores de combinación suma "+
" y resta "-
", lo que da lugar a un delegado de multidifusión (multicast delegate).
En nuestro código, creamos el nuevo delegado de multidifusión result
combinando sum
y mult
, que son los dos delegados que se suman. Por otra parte, la resta de sub
es simplemente una maniobra de distracción, pues se intentará eliminar de la combinación un delegado que no existía previamente, por lo que la operación será ignorada.
var result = sum - sub + mul;
Tras ejecutar esta línea, result
será un Func<int, int, int>
cuya invocación provocará que se ejecuten secuencialmente, y por orden de llegada, los delegados que han sido combinados.
Por tanto, cuando se evalúa la expresión result(3, 2)
, se ejecutará primero la función sum(3, 2)
y luego mul(3, 2)
, y será el resultado de esta última la que se retorne finalmente. De ahí obtenemos el 6
que va a la consola.
¿Qué, habías acertado?
Publicado en Variable not found.
La cuestión es: ¿por qué no compila el siguiente código?
class Program {
public static void Main() {
int f = 0; int x = 0; int y = 0;
System.Console.WriteLine(
"{0} {1}",
f < x, // is f smaller than x?
y > (-1) // is y greater than -1?
);
}
}
Imagen original de Pixabay.
La historia consiste en abusar del amplio conjunto de caracteres soportado por UTF, sustituyendo el punto y coma de finalización de una línea de código (";") por el símbolo de interrogación griego (";", Unicode 037E), indistinguibles a simple vista, como en la siguiente línea:
public void HelloWorld() { Console.WriteLine("Hello world!"); }
El asunto era que un usuario que quería saber cuál era el nombre del operador “-->” existente en muchísimos lenguajes, como podéis comprobar en un código perfectamente válido y compilable en C# como el siguiente:
static void Main(string[] args) { int x = 10; while (x --> 0) // while x goes to 0 { Console.Write(x); } // Shows: 9876543210 }
¿Y cómo se llama ese operador? No puedo negar que al principio me quedé un poco descolocado, como probablemente os haya ocurrido a algún despistado más, pero al leer las respuestas el tema quedaba bien claro que es sólo una cuestión de legibilidad de código, o mejor dicho, de falta de ella, acompañado de un comentario algo desafortunado que incita a la confusión. Complejidad innecesaria en cualquier caso.
En realidad, se trata de dos operadores seguidos, autodecremento y comparación, utilizados de forma consecutiva y abusando de las reglas de precendencia. Sin duda habría quedado mucho más claro de cualquiera de estas formas:
// Mejor: usar los espacios apropiadamente while (x-- > 0) { Console.Write(x); } // Mucho mejor: usar paréntesis para dejar explícitas las precendencias while ((x--) > 0) { Console.Write(x); } // Lo más claro: no liarse con expresiones complejas while (x > 0) { x--; Console.Write(x); }Este tema lo publicó también Eric Lippert hace algunos años como broma del fool’s day, anunciando un operador que habían añadido a última hora a C# 4.0, aunque al parecer es algo que ya circulaba antes por la red.
En fin, lo que me resultó curioso y quería mostraros en este post es cómo unos simples espacios pueden hacernos ver operadores donde no los hay, introducirnos dudas incluso en algo tan conocido como son los operadores de nuestro lenguaje de programación favorito, y hacer que de un vistazo no entendamos el código que tenemos delante.
Pero ya sabéis: si queréis parecer muy inteligentes y aumentar vuestro ratio de WTFs/minuto en la próxima revisión de código, no dudéis en usarlo ;)
Y si queréis ser ya los reyes de vuestro equipo, tampoco dudéis en usar el operador inverso “<--" que sube un peldaño adicional en el nivel de absurdo:
static void Main(string[] args) { int x = 10; while (0 <-- x) // while 0 is approached by x { Console.Write(x); } // Shows: 987654321 }
Publicado en Variable not found.