c++ - lenguaje - que es if else en programacion
Pro/Con: Inicializando una variable en una declaración condicional (10)
En C ++ puedes inicializar una variable en una instrucción if, así:
if (CThing* pThing = GetThing())
{
}
¿Por qué uno consideraría este estilo malo o bueno? ¿Cuáles son los beneficios y desventajas?
Personalmente, me gusta este estilo porque limita el alcance de la variable pThing, por lo que nunca se puede usar accidentalmente cuando es NULL. Sin embargo, no me gusta que no puedas hacer esto:
if (CThing* pThing = GetThing() && pThing->IsReallySomeThing())
{
}
Si hay una manera de hacer que lo anterior funcione, por favor publíquelo. Pero si eso no es posible, me gustaría saber por qué.
Es una buena y aceptable práctica de codificación. Sin embargo, las personas que no provienen de un fondo de codificación de bajo nivel probablemente estarían en desacuerdo.
Esto no debería funcionar en C ++, ya que aunque admite la evaluación de cortocircuito . Tal vez no intente lo siguiente:
if ((CThing* pThing = GetThing()) && (pThing->IsReallySomeThing()))
{
}
err .. ver la respuesta de Wesley Tarle
Lo importante es que una declaración en C ++ no es una expresión.
bool a = (CThing* pThing = GetThing()); // not legit!!
No se puede hacer una declaración y una lógica booleana en una instrucción if, la especificación del lenguaje C ++ permite específicamente una expresión o una declaración.
if(A *a = new A)
{
// this is legit and a is scoped here
}
¿Cómo podemos saber si a se define entre un término y otro en una expresión?
if((A *a = new A) && a->test())
{
// was a really declared before a->test?
}
Muerde la bala y usa un if interno. Las reglas de alcance son útiles y tu lógica es explícita:
if (CThing* pThing = GetThing())
{
if(pThing->IsReallySomeThing())
{
}
}
Sobre las ventajas:
Siempre se recomienda definir variables cuando las necesita por primera vez, no una línea antes. Esto es para una mejor legibilidad de su código, ya que uno puede saber qué es CThing sin desplazarse y buscar donde se definió.
Además, al reducir el alcance a un bloque loop / if, la variable no se referenciará después de la ejecución del bloque de código, lo que lo convierte en candidato para Garbage Collection (si el idioma admite esta característica).
Solo un FYI algunos de los antiguos cumplidores de C ++ de Microsoft (creo que Visual Studios 6 y .NET 2003) no siguen la regla del alcance en algunos casos.
for(int i = 0; i > 20; i++) {
// some code
}
cout << i << endl;
Debería estar fuera del alcance, pero ese era / es código válido. Creo que se jugó como una función, pero en mi opinión es simplemente incumplimiento. No cumplir con los estándares es malo. Solo como desarrollador web sobre IE y Firefox.
¿Alguien con VS puede verificar y ver si todavía es válido?
También observe que si está escribiendo código C ++, desea hacer que el compilador advierta sobre "=" en una declaración condicional (que no es parte de una declaración) un error.
También puede adjuntar la asignación en un conjunto adicional de () para evitar el mensaje de advertencia.
Una razón por la que normalmente no hago eso es debido a la falla común de una '''' ''perdida en una prueba condicional. Uso pelusa con el error / advertencias establecidos para capturarlos. Luego gritará sobre todas las asignaciones dentro de condicionales.
Veo eso como algo peligroso. El siguiente código es mucho más seguro y las llaves adjuntas aún limitarán el alcance de la manera que desee.
Supongo que GetThing () a veces devuelve NULL, por lo que puse esa cláusula divertida en la declaración if (). Impide que se llame a IsReallySomething () en un puntero NULL.
{
CThing *pThing = GetThing();
if(pThing ? pThing->IsReallySomeThing() : false)
{
// Do whatever
}
}
if (CThing* pThing = GetThing())
Es un estilo malo , porque dentro de if no está proporcionando una expresión booleana. Está proporcionando un CThing* .
CThing* pThing = GetThing();
if (pThing != NULL)
Este es un buen estilo.