tutorialspoint test sentencia example else c if-statement

test - sentencia if jsp



¿Cuál es el propósito de un bloque ''if(0)'' en el bloque if-else? (15)

Algunas veces uso esto para la simetría, de modo que puedo mover al else if{ estoy libremente con mi editor sin tener que preocuparme del primero if .

Semánticamente el

if (0) { // Empty braces } else

parte no hace nada y puede contar con optimizadores para eliminarla.

Mi pregunta es sobre la línea que he mencionado en el tema y que puedo ver en muchos lugares dentro del código de producción.

El código general se ve así:

if (0) { // Empty braces } else if (some_fn_call()) { // actual code } else if (some_other_fn_call()) { // another actual code ... } else { // default case }

Las otras ramas son irrelevantes para mi pregunta. Me pregunto cuál es el significado de poner if (0) aquí. Las llaves están vacías, así que no creo que deba comentar algún bloque de código. ¿Obliga al compilador a realizar alguna optimización o son diferentes sus intenciones?

He intentado buscar este caso explícito aquí en SO y en Internet, pero sin éxito. Hay preguntas similares sobre JavaScript, pero no C. Hay otra pregunta, ¿Qué sucede cuando se asigna un cero en una condición `if`? , pero analiza la asignación de cero a una variable, no el uso ''if (0)'' en sí.


Ayuda a depurar este bloque solo poniendo el bloque 1. Esto deshabilita todas las funciones del bloque si no. Y también podemos ampliar el bloque if else.


Como está escrito, la cláusula if (0) {} compila a la nada.

Sospecho que la función de la cláusula en la parte superior de esta escalera es proporcionar un lugar fácil para deshabilitar temporalmente todas las otras funciones a la vez (para fines de depuración o comparación) cambiando el 0 a 1 o true .


Como se ha dicho, el cero se evalúa como falso y el compilador probablemente optimice la rama.

También he visto esto antes en el código donde se agregó una nueva función y se necesitaba un interruptor de interrupción (si algo falla con la función, simplemente puede desactivarla), y algún tiempo después, cuando se eliminó el interruptor de muerte, El programador no eliminó la rama, por ejemplo.

if (feature_a_active()) { use_feature_a(); } else if (some_fn()) { ...

convirtió

if (0) { // empty } else if (some_fn()) { ...


Creo que es solo un código malo. Escribiendo un ejemplo rápido en Compiler Explorer, vemos que tanto en gcc como en clang no se genera ningún código para el bloque if (0) , incluso con las optimizaciones completamente desactivadas:

https://godbolt.org/z/PETIks

Jugar con eliminar el if (0) no provoca cambios en el código generado, por lo que llego a la conclusión de que esto no es una optimización.

Es posible que haya algo en la parte superior if bloque se eliminó más tarde. En resumen, parece que eliminarlo causaría que se genere exactamente el mismo código, así que siéntase libre de hacerlo.


Esa construcción también se puede usar en C para implementar la programación genérica con seguridad de tipo, confiando en el hecho de que el compilador sigue comprobando el código inalcanzable:

// this is a generic unsafe function, that will call fun(arg) at a later time void defer(void *fun, void *arg); // this is a macro that makes it safer, by checking the argument // matches the function signature #define DEFER(f, arg) / if(0) f(arg); / // never actually called, but compile-time checked else defer(f, (void *)arg); // do the unsafe call after safety check void myfunction(int *p); DEFER(myfunction, 42); // compile error int *b; DEFER(myfunction, b); // compiles OK


Esto puede ser útil si hay sentencias #if , ala

if (0) { // Empty block } #if TEST1_ENABLED else if (test1()) { action1(); } #endif #if TEST2_ENABLED else if (test2()) { action2(); } #endif

etc.

En este caso, todas las pruebas (y todas) pueden ser #if , y el código se compilará correctamente. Casi todos los compiladores eliminarán la parte if (0) {} . Un autogenerador simple podría generar código como este, ya que es un código un poco más fácil, no tiene que considerar el primer bloque habilitado por separado.


He visto bloques de código no accesibles en JavaScript pre-expandido que se han generado usando un lenguaje de plantillas.

Por ejemplo, el código que está leyendo podría haber sido pegado desde un servidor que evaluó previamente la primera condición que en ese momento dependía de una variable solo disponible en el lado del servidor.

if ( ${requestIsNotHttps} ){ ... }else if( ...

que una vez pre-compilado hences:

if ( 0 ){ ... }else if ( ...

¡Espero que esto le ayude a relativizar la baja actividad potencial del teclado de la era de los codificadores pro-reciclaje por la que manifiesto entusiasmo!


He visto esto varias veces, creo que la razón más probable es que estaba evaluando algo en una versión / rama antigua / diferente del código, o posiblemente para la depuración, y cambiarlo a if(0) es una forma un tanto perezosa de eliminando lo que estaba allí.


He visto un patrón similar utilizado en el código generado. Por ejemplo, en SQL, he visto que las bibliotecas emiten la siguiente cláusula where .

where 1 = 1

Esto presumiblemente hace que sea más fácil simplemente agregar otros criterios, ya que todos los criterios adicionales pueden ir precedidos and lugar de una verificación adicional para ver si es el primer criterio o no.


La respuesta de @ PSkocik está bien, pero agrego mis dos centavos. No estoy seguro si debo hacer esto como un comentario, o como una respuesta; elegir el último, porque IMHO vale la pena ver, mientras que los comentarios son frecuentemente invisibles.

No solo uso ocasionalmente

if(0) { //deliberately left empty } else if( cond1 ) { //deliberately left empty } else if( cond2 ) { //deliberately left empty ... } else { // no conditions matched }

Pero también ocasionalmente hago

if( 1 && cond1 && cond2 ... && condN ) {

o

if( 0 || cond1 || cond2 ... || condN ) {

Para condiciones complicadas. Por las mismas razones - más fácil de editar, #ifdef, etc.

Para el caso, en Perl lo haré.

@array = ( elem1, elem2, ... elem1, ) {

  • Anote la coma al final de la lista. Olvido si las comas son separadores o delimitadores en las listas C y C ++. En mi humilde opinión, esto es una cosa que hemos aprendido: [ ¿Es una mala práctica el uso de comas en Perl? comas] son ​​una buena cosa. Como cualquier nueva notación, se tarda un poco en acostumbrarse.

Yo comparo el código if(0) con lisp

(cond (test1 action1) (test2 action2) ... (testn actionn))

que, lo has adivinado, puedo sangrar como

(cond (test1 action1) (test2 action2) ... (testn actionn) )

A veces he tratado de imaginar cómo sería una sintaxis más legible para los humanos.

Quizás

IF :: cond1 THEN code1 :: cond2 THEN code2 ... :: condN THEN codeN FI

inspirado por el [ https://en.wikipedia.org/wiki/Guarded_Command_Language#Selection:_if][Guarded Idioma del comando guardado] de Dikstra.

Pero esta sintaxis implica que las condiciones se evalúan en paralelo, mientras que if...else-if implica una evaluación de condiciones secuencial y priorizada.

Comencé a hacer este tipo de cosas al escribir programas que generaban otros programas, donde es especialmente conveniente.

Mientras estamos en eso, cuando escribo RTL usando el antiguo iHDL de Intel, he codificado cosas como

IF 0 THEN /*nothing*/ **FORC i FROM 1 TO 10 DOC** ELSE IF signal%i% THEN // stuff to do if signal%i% is active **ENDC** ELSE // nothing matched ENDIF

donde FORC..DOC..ENDC es una construcción de bucle de preprocesador de macros, que se expande a

IF 0 THEN /*nothing*/ ELSE IF signal1 THEN // stuff to do if signal1 is active ELSE IF signal2 THEN // stuff to do if signal2 is active ... ELSE IF signal100 THEN // stuff to do if signal100 is active ELSE // nothing matched ENDIF

Este era un código de asignación única, no imperativo, por lo que no se permitía establecer una variable de estado, si era necesario hacer cosas como encontrar el primer bit de configuración.

IF 0 THEN /*nothing*/ ELSE IF signal1 THEN found := 1 ELSE IF signal2 THEN found := 2 ... ELSE IF signal100 THEN found := 100 ELSE // nothing matched ENDIF

Ahora que lo pienso, este puede haber sido el primer lugar en el que encontré tales construcciones.

Por cierto, las objeciones que algunos tenían al estilo if (0), que las condiciones de else-if-son secuencialmente dependientes y no se pueden reordenar arbitrariamente, no se aplican a las lógicas AND y OR y XOR en RTL, pero sí se aplican al corto circuito && y ||.


No estoy seguro de ninguna optimización, pero mis dos centavos:

Esto sucedió debido a alguna modificación del código, donde se eliminó una condición primaria, (la función call in initial if block, digamos), pero los desarrolladores / mantenedores

así que en lugar de eliminar el bloque if asociado, simplemente cambiaron la condición a if(0) y siguieron adelante.


Una posibilidad aún no mencionada: la línea if (0) { podría proporcionar un lugar conveniente para un punto de interrupción.

La depuración a menudo se realiza en un código no optimizado, por lo que la prueba siempre falsa estará presente y podrá tener un punto de interrupción establecido. Cuando se compila para la producción, la línea de código se optimiza. La línea aparentemente inútil proporciona funcionalidad para las compilaciones de desarrollo y prueba sin impactar las compilaciones de lanzamiento.

Hay otras buenas sugerencias arriba también; La única forma de saber realmente cuál es el propósito es rastrear al autor y preguntar. Su sistema de control de código fuente podría ayudar con eso. (Busque la funcionalidad de tipo blame ).


Es el código podrido.

En algún momento, el "si" hizo algo útil, la situación cambió, tal vez se eliminó la variable que se está evaluando.

La persona que estaba arreglando / cambiando el sistema hizo lo menos posible para afectar la lógica del sistema, por lo que se aseguró de que el código se recompilara. Así que deja un "si (0)" porque es rápido y fácil y no está totalmente seguro de lo que quiere hacer. Él hace que el sistema funcione y no vuelve a arreglarlo por completo.

Luego aparece el siguiente desarrollador y piensa que se hizo deliberadamente y solo comenta esa parte del código (ya que no se está evaluando de todos modos), luego, la próxima vez que se toque el código, se eliminarán esos comentarios.


Actually according to my opinion, if we put any variable for checking inside e.g:- public static void main(string args[]) { var status; var empList=_unitofWork.EmpRepository.Get(con=>con.isRetired==true); //some code logic if(empList.count>0) { status=true; } if(status) { //do something } else { //do something else } } if then its dynamically get the value in run time and invoke the logic inside it, else its simply extra line of code i guess. Anybody have any depth knowledge why this thing is used....or agree with me. kindly respond.