do {…} while (falso)

Estaba mirando un código por un individuo y noté que parece tener un patrón en sus funciones:

<return-type> function(<params>)
{
 <initialization>

 do
 {
   <main code for function>
 }
 while(false);

 <tidy-up & return>
}

No está mal , es más peculiar (el código real es bastante ordenado y no sorprende). No es algo que haya visto antes y me preguntaba si alguien puede pensar en alguna lógica detrás de él, ¿quizás en un idioma diferente?

Puedes breaksalir de do{...}while(false).

Mucha gente señala que a menudo se usa con break como una forma incómoda de escribir "goto". Eso probablemente sea cierto si está escrito directamente en la función.

En una macro, OTOH, do { something; } while (false)es una forma conveniente de FORZAR un punto y coma después de la invocación de la macro, absolutamente ningún otro token puede seguir.

Y otra posibilidad es que haya una vez un bucle allí o se anticipe que se agregará iteración en el futuro (por ejemplo, en el desarrollo basado en pruebas, no fue necesaria la iteración para pasar las pruebas, pero lógicamente tendría sentido hacerlo allí si la función debía ser algo más general de lo que se requiere actualmente)

El descanso como goto es probablemente la respuesta, pero propondré otra idea.

Tal vez quería tener variables definidas localmente y usó esta construcción para obtener un nuevo alcance.

Recuerde que si bien C ++ reciente permite {...}cualquier lugar, este no siempre fue el caso.

He visto que se usa como un patrón útil cuando hay muchos puntos de salida potenciales para la función, pero siempre se requiere el mismo código de limpieza independientemente de cómo salga la función.

Puede hacer que un árbol cansador if / else-if sea mucho más fácil de leer, simplemente teniendo que romperse cada vez que se alcanza un punto de salida, con el resto de la lógica en línea después.

Este patrón también es útil en idiomas que no tienen una instrucción goto. Quizás ahí es donde el programador original aprendió el patrón.

He visto un código así para que pueda usarlo breakcomo una gotoespecie de.

Esto es solo una perversión de whileobtener la semántica de goto tidy-upsin usar la palabra goto.

Es de mal gusto ya que al usar otros circuitos en el interior del exterior de whilela breaksvuelven ambiguos para el lector. "¿Se supone que esto tiene que salir? ¿O está destinado solo a salir del circuito interno?"

Creo que es más conveniente escribir en breaklugar de goto end. Ni siquiera tiene que pensar en un nombre para la etiqueta que aclare la intención: no desea saltar a una etiqueta con un nombre específico. Quieres salir de aquí.

También es probable que necesite los frenos de todos modos. Entonces esta es la do{...}while(false);versión:

do {
   // code
   if (condition) break; // or continue
   // more code
} while(false);

Y esta es la forma en que tendrías que expresarlo si quisieras usar goto:

{
   // code
   if (condition) goto end;
   // more code
}
end:

Creo que el significado de la primera versión es mucho más fácil de entender. También es más fácil de escribir, más fácil de extender, más fácil de traducir a un idioma que no es compatible goto, etc.

La preocupación más frecuentemente mencionada sobre el uso de breakes que está muy mal disfrazada goto. Pero en realidad breaktiene más parecido a return: Ambas instrucciones saltan de un bloque de código que está más o menos estructurado en comparación con goto. Sin embargo, ambas instrucciones permiten múltiples puntos de salida en un bloque de código que a veces puede ser confuso. Después de todo, trataría de buscar la solución más clara, cualquiera que sea la situación específica.

Este truco lo usan los programadores que son demasiado tímidos para usar un gotocódigo explícito . El autor del código anterior quería tener la capacidad de saltar directamente al punto de "limpieza y retorno" desde la mitad del código. Pero no querían usar una etiqueta explícita goto. En cambio, pueden usar el breakinterior del cuerpo del ciclo "falso" anterior para lograr el mismo efecto.

Es una práctica muy común. En do . Trato de pensar en ello como si quisieras mentirte a ti mismo de una manera "No estoy usando un goto". Pensando en ello, no habría nada de malo con un gotouso similar. De hecho, también reduciría el nivel de sangría.

Sin embargo, dicho esto, noté, muy a menudo estos do..whilebucles tienden a crecer. Y luego obtienen ifsys elsedentro, lo que hace que el código en realidad no sea muy legible, y mucho menos comprobable.

Esos do..whilenormalmente están destinados a hacer una limpieza . Por todos los medios posibles, preferiría usar RAII y regresar temprano de una función corta . Por otro lado, C no le brinda tantas comodidades como lo hace C ++ , por lo que es do..whileuno de los mejores enfoques para hacer una limpieza.

Parece un programador en C. En C ++, las variables automáticas tienen destructores que se usan para limpiar, por lo que no debe haber nada necesario para ordenar antes del regreso. En C, no tenía este modismo RAII , por lo que si tiene un código de limpieza común, lo gotousa o usa un ciclo de paso único como se indicó anteriormente.

Su principal desventaja en comparación con el idioma de C ++ es que no se ordenará si se produce una excepción en el cuerpo. C no tenía excepciones, así que esto no fue un problema, pero sí lo convierte en un mal hábito en C ++.

Varias explicaciones El primero es general, el segundo es específico para macros de preprocesador C con parámetros:

Control de flujo

He visto esto usado en código C simple. Básicamente, es una versión más segura de goto, ya que puede salir de ella y toda la memoria se limpia correctamente.

¿Por qué algo gotobueno sería bueno? Bueno, si usted tiene código donde prácticamente cada línea puede devolver un error, pero que necesita para reaccionar a todos ellos de la misma manera (por ejemplo, mediante la presentación del error al que llama después de limpiar), por lo general es más fácil de leer para evitar una if( error ) { /* cleanup and error string generation and return here */ }como evita la duplicación del código de limpieza.

Sin embargo, en C ++ tiene excepciones + RAII exactamente para este propósito, por lo que lo consideraría un mal estilo de codificación.

Comprobación de punto y coma

Si olvida el punto y coma después de una invocación de macro similar a una función, los argumentos pueden contraerse de forma no deseada y compilarse en una sintaxis válida. Imagina la macro

#define PRINT_IF_DEBUGMODE_ON(msg) if( gDebugModeOn ) printf("foo");

Eso se llama accidentalmente como

if( foo )
    PRINT_IF_DEBUGMODE_ON("Hullo\n")
else
    doSomethingElse();

El "más" se considerará asociado con el gDebugModeOn, por lo tanto, cuando foosea false, sucederá exactamente lo contrario de lo que se pretendía.

Proporcionando un alcance para variables temporales.

Dado que do / while tiene llaves, las variables temporales tienen un alcance claramente definido del que no pueden escapar.

Evitar advertencias de "punto y coma posiblemente no deseado"

Algunas macros solo se activan en versiones de depuración. Los define como:

#if DEBUG
#define DBG_PRINT_NUM(n) printf("%d\n",n);
#else
#define DBG_PRINT_NUM(n) 
#endif

Ahora, si usa esto en una versión de lanzamiento dentro de un condicional, se compila a

if( foo )
    ;

Muchos compiladores ven esto como lo mismo que

if( foo );

Que a menudo se escribe accidentalmente. Entonces recibes una advertencia. Do {} while (false) oculta esto del compilador y es aceptado por él como una indicación de que realmente no desea hacer nada aquí.

Evitar la captura de líneas por condicionales

Macro del ejemplo anterior:

if( foo )
    DBG_PRINT_NUM(42)
doSomething();

Ahora, en una compilación de depuración, ya que habitualmente también incluimos el punto y coma, esto se compila muy bien. Sin embargo, en la versión de lanzamiento, esto de repente se convierte en:

if( foo )

doSomething();

O más claramente formateado

if( foo )
    doSomething();

Lo cual no es en absoluto lo que se pretendía. Agregar un do {...} while (falso) alrededor de la macro convierte el punto y coma faltante en un error de compilación.

¿Qué significa eso para el OP?

En general, desea utilizar excepciones en C ++ para el manejo de errores y plantillas en lugar de macros. Sin embargo, en el caso muy raro en el que todavía necesita macros (por ejemplo, cuando genera nombres de clase usando pegado de token) o está restringido a C simple, este es un patrón útil.

Tal vez se usa para que breakpueda usarse dentro para abortar la ejecución de código adicional en cualquier momento:

do {
    if (!condition1) break;
    some_code;
    if (!condition2) break;
    some_further_code;
    // …
} while(false);

Creo que esto se hace para usar breako continuedeclaraciones. Algún tipo de lógica de código "goto".

Es simple: aparentemente puedes salirte del bucle falso en cualquier momento usando la breakdeclaración. Además, el dobloque es un alcance separado (que también se podría lograr { ... }solo).

En tal situación, podría ser una mejor idea usar RAII (los objetos se destruyen automáticamente cuando finaliza la función). Otra construcción similar es el uso de goto: sí, sé que es malo , pero se puede usar para tener un código de limpieza común como este:

<return-type> function(<params>)
{
 <initialization>

 <main code for function using "goto error;" if something goes wrong>

 <tidy-up in success case & return>

 error:

 <commmon tidy-up actions for error case & return error code or throw exception>
}

(Como comentario aparte: la construcción do-while-false se usa en Lua para encontrar la continuedeclaración que falta ).

Muchos respondedores dieron la razón do{(...)break;}while(false). Me gustaría complementar la imagen con otro ejemplo más de la vida real.

En el siguiente código, tuve que establecer un enumerador operationbasado en la dirección apuntada por el datapuntero. Debido a que una caja de cambio solo se puede usar en tipos escalares primero, lo hice de manera ineficiente de esta manera

if (data == &array[o1])
    operation = O1;
else if (data == &array[o2])
    operation = O2;
else if (data == &array[on])
    operation = ON;

Log("operation:",operation);

Pero como Log () y el resto del código se repiten para cualquier valor de operación elegido, estaba divagando cómo omitir el resto de las comparaciones cuando la dirección ya se ha descubierto. Y aquí es dondedo{(...)break;}while(false) resulta útil.

do {
    if (data == &array[o1]) {
        operation = O1;
        break;
    }
    if (data == &array[o2]) {
        operation = O2;
        break;
    }
    if (data == &array[on]) {
        operation = ON;
        break;
    }
} while (false);

Log("operation:",operation);

Uno puede preguntarse por qué no podría hacer lo mismo breaken unif declaración, como:

if (data == &array[o1])
{
    operation = O1;
    break;
}
else if (...)

breakinteractúa únicamente con el cerramiento más cercano de bucle o un interruptor, ya sea una for, whileo do .. whiletipo, por lo que lamentablemente eso no va a funcionar.

¿Cuántos años tenía el autor?

Pregunto porque una vez me encontré con un código Fortran en tiempo real que hizo eso, a fines de los años 80. Resulta que es una muy buena manera de simular hilos en un sistema operativo que no los tiene. Simplemente coloca todo el programa (su programador) en un bucle y llama a sus rutinas de "subproceso" una por una. Las rutinas de subprocesos en sí son bucles que se repiten hasta que ocurre una de una serie de condiciones (a menudo una es una cierta cantidad de ha pasado el tiempo). Es "multitarea cooperativa", ya que depende de los hilos individuales abandonar la CPU de vez en cuando para que los demás no se mueran de hambre. Puede anidar las llamadas de subprograma en bucle para simular la prioridad del hilo bandas.

Además de los 'ejemplos de goto' ya mencionados, el idioma do ... while (0) a veces se usa en una definición de macro para proporcionar corchetes en la definición y aún hacer que el compilador funcione agregando un punto y coma al final de Una llamada macro.

http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/52f670f1292f30a4?tvc=2&q=while+(0)

Estoy de acuerdo con la mayoría de los carteles sobre el uso como un goto apenas disfrazado. Las macros también se han mencionado como una motivación potencial para escribir código en el estilo.

También he visto esta construcción utilizada en entornos mixtos C / C ++ como la excepción de un hombre pobre. El "do {} while (false)" con un "break" se puede usar para saltar al final del bloque de código en caso de que se encuentre algo que normalmente garantizaría una excepción en el bucle.

También he enviado esta construcción utilizada en tiendas donde se aplica la ideología de "retorno único por función". Nuevamente, esto es en lugar de un "goto" explícito, pero la motivación es evitar múltiples puntos de retorno, no "omitir" el código y continuar la ejecución real dentro de esa función.

Trabajo con Adobe InDesign SDK, y los ejemplos de InDesign SDK tienen casi todas las funciones escritas de esta manera. Es debido al hecho de que la función suele ser realmente larga. Donde necesita hacer QueryInterface (...) para obtener cualquier cosa del modelo de objetos de la aplicación. Por lo general, cada QueryInterface es seguido por ifno salió bien, descanso.

Muchos ya han declarado la similitud entre este constructo y a goto, y expresaron una preferencia por el goto. ¿Quizás los antecedentes de esta persona incluían un entorno donde los goto estaban estrictamente prohibidos por las pautas de codificación?

La otra razón por la que se me ocurre es que decora los aparatos ortopédicos, mientras que creo que los aparatos desnudos estándar más nuevos de C ++ no están bien (a ISO C no le gustan). De lo contrario, para silenciar un analizador estático como pelusa.

No estoy seguro de por qué los querría, tal vez alcance variable o ventaja con un depurador.

Ver Trivial Do While loop , y las llaves son buenas de C2.

Para aclarar mi terminología (que creo que sigue el uso estándar):

Tirantes desnudos :

init();
...
{
c = NULL;
mkwidget(&c);
finishwidget(&c);
}
shutdown();

Tirantes vacíos (NOP):

{}

p.ej

while (1)
   {}  /* Do nothing, endless loop */

Bloque :

if (finished)
{
     closewindows(&windows);
     freememory(&cache);
}

que se convertiría

if (finished)
     closewindows(&windows);
freememory(&cache);

si se eliminan las llaves, alterando así el flujo de ejecución, no solo el alcance de las variables locales. Por lo tanto, no 'independiente' o 'desnudo'.

Se pueden usar llaves desnudas o un bloque para indicar cualquier sección de código que pueda ser una función (en línea) que desee marcar, pero no refactorizar en ese momento.

Es una forma artificial de emular a GOTOya que estos dos son prácticamente idénticos:

// NOTE: This is discouraged!
do {
    if (someCondition) break;
    // some code be here
} while (false);
// more code be here

y:

// NOTE: This is discouraged, too!
if (someCondition) goto marker;
// some code be here
marker:
// more code be here

Por otro lado, ambos realmente deberían hacerse con ifs:

if (!someCondition) {
    // some code be here
}
// more code be here

Aunque el anidamiento puede volverse un poco feo si solo convierte una larga cadena de reenvíos GOTOen anidados if. Sin embargo, la respuesta real es una refactorización adecuada, sin imitar construcciones de lenguaje arcaico.

Si intentabas desesperadamente transliterar un algoritmo con GOTOs, probablemente podrías hacerlo con este modismo. Sin embargo, no es estándar y es un buen indicador de que no te estás apegando a los modismos esperados del idioma.

No conozco ningún lenguaje tipo C donde do / while sea una solución idiomática para nada, en realidad.

Probablemente podría refactorizar todo el desastre en algo más sensato para hacerlo más idiomático y mucho más legible.

Algunos codificadores prefieren tener una única salida / retorno de sus funciones. El uso de un dummy do {....} while (falso); le permite "salir" del bucle ficticio una vez que haya terminado y aún tenga un solo retorno.

Soy un programador de Java, así que mi ejemplo sería algo así como

import java.util.Arrays;
import java.util.List;
import java.util.Set;
import java.util.stream.Collectors;
import java.util.stream.Stream;

public class p45
{
    static List<String> cakeNames = Arrays.asList("schwarzwald torte", "princess", "icecream");
    static Set<Integer> forbidden = Stream.of(0, 2).collect(Collectors.toSet());

    public static  void main(String[] argv)
    {
        for (int i = 0; i < 4; i++)
        {
            System.out.println(String.format("cake(%d)=\"%s\"", i, describeCake(i)));
        }
    }


    static String describeCake(int typeOfCake)
    {
        String result = "unknown";
        do {
            // ensure type of cake is valid
            if (typeOfCake < 0 || typeOfCake >= cakeNames.size()) break;

            if (forbidden.contains(typeOfCake)) {
                result = "not for you!!";
                break;
            }

            result = cakeNames.get(typeOfCake);
        } while (false);
        return result;
    }
}

En tales casos yo uso

switch(true) {
   case condution1:
      ...
      break;
   case condution2:
      ...
      break;
}

Esto es divertido Probablemente hay interrupciones dentro del ciclo como otros han dicho. Lo hubiera hecho de esta manera:

while(true)
{
   <main code for function>
   break; // at the end.
}