c++ - traductor - unless oraciones

¿Hay alguna razón para usar if(1 ||! Foo())?

Question

Leí un código heredado:

if ( 1 || !Foo() )

¿Hay alguna razón por la que no se escribe?

if ( !Foo() )

Answer 1

La pregunta se contestó correctamente: la diferencia es que el lado derecho de la operación está cortocircuitado, lo que sugiere que se trata de un código de depuración para forzar la entrada al bloque if.

Pero, en aras de las mejores prácticas, al menos mi puñalada en la mejor práctica, sugeriría alternativas, en orden de preferencia creciente (la mejor es la última):

Nota: notado después de que codifiqué ejemplos esta era una pregunta de C ++, los ejemplos son C #. Espero que puedas traducir. Si alguien me necesita, solo publique un comentario.

Comentario en línea:

if (1 /*condition*/) //temporary debug

Comentario fuera de línea:

//if(condition)
if(true) //temporary debug

Nombre-Función Indicativa

//in some general-use container
bool ForceConditionForDebug(bool forcedResult, string IgnoredResult)
{
      #if DEBUG
          Debug.WriteLine(
              string.Format(
                  "Conditional {0} forced to {1} for debug purposes",
                  IgnoredResult,
                  forcedResult));
          return forcedResult;
      #else
          #if ALLOW_DEBUG_CODE_IN_RELEASE
              return forcedResult;
          #else
              throw new ApplicationException("Debug code detected in release mode");
          #endif
      #endif
}

//Where used
if(ForceConditionForDebug(true, "condition"))...

//Our case
if(ForceConditionForDebug(true, "!Foo()"))...

Y si quería una solución realmente robusta, podría agregar una regla de repositorio al control de origen para rechazar cualquier código ingresado que llame a ForceConditionForDebug. Este código nunca debería haber sido escrito de esa manera porque obviamente no comunica intenciones. Nunca debería haberse registrado (o se le ha permitido registrarse) (¿control de fuente? ¿Revisión por pares?) Y definitivamente nunca se debe permitir que se ejecute en producción en su forma actual.

Answer 2

Los dos no son lo mismo. El primero nunca evaluará Foo() porque el 1 cortocircuita el || .

¿Por qué está hecho? Probablemente alguien quería forzar la entrada en la sucursal de then con fines de depuración y lo dejó allí. También podría ser que esto se escribió antes del control de fuente, por lo que no querían que el código se perdiera, sino que simplemente se pasa por alto por el momento .

Answer 3

if (1 || !Foo() ) siempre estará satisfecho. !Foo() ni siquiera se alcanzará debido a la evaluación de cortocircuitos .

Esto sucede cuando desea asegurarse de que se ejecutará el código debajo de if , pero no desea eliminar la condición real en él, probablemente con fines de depuración.

Información adicional que podría ayudarlo:

• if(a && b) - si a es false , b no se marcará.
• if(a && b) - si a es true , b será verificado, porque si es false , la expresión será false .
• if(a || b) - si a es true , b no se verificará, porque de todos modos es true .
• if(a || b) - si a es false , b será verificado, porque si b es true entonces será true .

Se recomienda encarecidamente tener una macro para este fin, digamos DEBUG_ON 1 , que hará que sea más fácil entender lo que significa el programador, y no tener números mágicos en el código (Gracias @grigeshchauhan).

Answer 4

1 || condition

siempre es cierto, independientemente de si la condition es verdadera o no. En este caso, la condition nunca se está evaluando. El siguiente código:

int c = 5;
if (1 || c++){}
printf("%d", c);

salidas 5 ya que c nunca se incrementa, sin embargo, si cambia de 1 a 0 , se llamará realmente a c++ , haciendo que la salida 6 .

Un uso práctico habitual de esto es la situación en la que desea probar algún fragmento de código que se invoca cuando la condición que se evalúa como verdadera solo se cumple pocas veces:

if (1 || condition ) {
    // code I want to test
}

De esta manera, la condition nunca se evaluará y, por lo tanto, // code I want to test siempre se invoca. Sin embargo, definitivamente no es lo mismo que:

if (condition) { ...

que es un enunciado en el que se evaluará realmente la condition (y en su caso se llamará a Foo )