do {…} while (false)

Stavo guardando un codice da un individuo e ho notato che sembra avere uno schema nelle sue funzioni:

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

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

 <tidy-up & return>
}

Non è male , più peculiare (il codice effettivo è abbastanza pulito e non sorprende). Non è qualcosa che ho visto prima e mi chiedevo se qualcuno possa pensare a qualche logica dietro di esso - forse sfondo in una lingua diversa?

Puoi breakuscire do{...}while(false).

Molte persone sottolineano che è spesso usato con break come un modo scomodo di scrivere "goto". Probabilmente è vero se è scritto direttamente nella funzione.

In una macro, OTOH, do { something; } while (false)è un modo conveniente per FORZARE un punto e virgola dopo il richiamo della macro, assolutamente nessun altro token può seguire.

E un'altra possibilità è che una volta c'era un loop lì o si prevede che l'iterazione verrà aggiunta in futuro (ad es. Nello sviluppo basato sui test, l'iterazione non era necessaria per superare i test, ma logicamente avrebbe senso eseguire il loop lì se la funzione doveva essere un po 'più generale di quella attualmente richiesta)

L'interruzione come goto è probabilmente la risposta, ma proporrò un'altra idea.

Forse voleva avere variabili definite localmente e ha usato questo costrutto per ottenere un nuovo ambito.

Ricorda che mentre il recente C ++ consente {...}ovunque, non è sempre stato così.

L'ho visto usato come un modello utile quando ci sono molti potenziali punti di uscita per la funzione, ma lo stesso codice di pulizia è sempre richiesto indipendentemente da come la funzione esce.

Può rendere un faticoso albero if / else-if molto più facile da leggere, semplicemente dovendo rompere ogni volta che viene raggiunto un punto di uscita, con il resto della logica in linea in seguito.

Questo modello è utile anche nelle lingue che non dispongono di un'istruzione goto. Forse è lì che il programmatore originale ha imparato il modello.

Ho visto codice del genere, quindi puoi usarlo breakcome una gotosorta di.

Questa è solo una perversione di whileottenere la sematica di goto tidy-upsenza usare la parola goto.

E 'di cattivo gusto, perché quando si utilizzano altri loop all'interno del esterna whiledel breaksdiventano ambigue al lettore. "Questo dovrebbe andare a uscire? O è destinato solo a rompere il ciclo interno?"

Penso che sia più conveniente scrivere breakinvece di goto end. Non devi nemmeno pensare a un nome per l'etichetta che renda più chiara l'intenzione: non vuoi saltare a un'etichetta con un nome specifico. Vuoi uscire di qui.

Inoltre è probabile che tu abbia comunque bisogno delle parentesi graffe. Quindi questa è la do{...}while(false);versione:

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

E questo è il modo in cui dovresti esprimerlo se volessi usare goto:

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

Penso che il significato della prima versione sia molto più facile da capire. Inoltre è più facile scrivere, più facile da estendere, più facile da tradurre in una lingua che non supporta goto, ecc.

La preoccupazione più frequentemente menzionata riguardo all'uso di breakè che è un male mascherato goto. Ma in realtà breakha più somiglianza con return: Entrambe le istruzioni saltano fuori da un blocco di codice che è più o meno strutturato rispetto a goto. Tuttavia entrambe le istruzioni consentono più punti di uscita in un blocco di codice che a volte può creare confusione. Dopotutto, cercherò di trovare la soluzione più chiara, qualunque cosa sia nella situazione specifica.

Questo trucco è usato dai programmatori che sono troppo timidi per usare un esplicito gotonel loro codice. L'autore del codice precedente voleva avere la possibilità di passare direttamente al punto "pulizia e restituzione" dalla metà del codice. Ma non volevano usare un'etichetta ed esplicito goto. Invece, possono utilizzare un breakall'interno del corpo del ciclo "falso" di cui sopra per ottenere lo stesso effetto.

È una pratica molto comune. In C . Cerco di pensarlo come se volessi mentire a te stesso in un modo "non sto usando un goto". A pensarci bene, non ci sarebbe nulla di sbagliato in un gotousato allo stesso modo. Infatti ridurrebbe anche il livello di indentazione.

Detto questo, però, ho notato, molto spesso questo do..whileloop tende a crescere. E poi ottengono ifs e elses all'interno, rendendo il codice in realtà non molto leggibile, figuriamoci testabile.

Quelli do..whilesono normalmente destinati a fare una pulizia . Con tutti i mezzi possibili preferirei usare RAII e tornare presto da una breve funzione. D'altra parte, il C non ti offre tante comodità come il C ++ , rendendo do..whileuno dei migliori approcci per fare una pulizia.

Sembra un programmatore C. In C ++, le variabili automatiche hanno distruttori che usi per ripulire, quindi non dovrebbe esserci nulla di necessario per riordinare prima del ritorno. In C, non avevi questo idioma RAII , quindi se hai un codice di ripulitura comune, gotolo o usi un ciclo una tantum come sopra.

Il suo principale svantaggio rispetto all'idioma C ++ è che non si riordina se viene lanciata un'eccezione nel corpo. Il C non aveva eccezioni, quindi questo non era un problema, ma lo rende una cattiva abitudine in C ++.

Diverse spiegazioni. Il primo è generale, il secondo è specifico per le macro del preprocessore C con parametri:

Controllo del flusso

L'ho visto usato nel semplice codice C. Fondamentalmente, è una versione più sicura di goto, poiché puoi uscirne e tutta la memoria viene ripulita correttamente.

Perché qualcosa di gotosimile dovrebbe essere buono? Bene, se hai un codice in cui praticamente ogni riga può restituire un errore, ma devi reagire a tutti allo stesso modo (ad esempio consegnando l'errore al chiamante dopo la pulizia), di solito è più leggibile evitare un if( error ) { /* cleanup and error string generation and return here */ }as evita la duplicazione del codice di pulizia.

Tuttavia, in C ++ hai eccezioni + RAII esattamente per questo scopo, quindi lo considererei un cattivo stile di codifica.

Controllo punto e virgola

Se dimentichi il punto e virgola dopo un'invocazione di una macro simile a una funzione, gli argomenti potrebbero contrarsi in modo indesiderato e compilarsi in una sintassi valida. Immagina la macro

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

Questo viene accidentalmente chiamato come

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

L '"altro" sarà considerato associato a gDebugModeOn, quindi quando fooè false, accadrà l'esatto contrario di ciò che era previsto.

Fornire un ambito per le variabili temporanee.

Poiché il do / while ha le parentesi graffe, le variabili temporanee hanno un ambito chiaramente definito da cui non possono sfuggire.

Evitare gli avvisi di "punto e virgola eventualmente indesiderato"

Alcune macro vengono attivate solo nelle build di debug. Li definisci come:

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

Ora, se lo usi in una build di rilascio all'interno di un condizionale, si compila in

if( foo )
    ;

Molti compilatori lo vedono come lo stesso di

if( foo );

Che è spesso scritto accidentalmente. Quindi ricevi un avviso. Il do {} while (false) lo nasconde al compilatore e viene accettato da esso come un'indicazione che non si vuole fare nulla qui.

Evitare l'acquisizione di linee da condizionali

Macro dell'esempio precedente:

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

Ora, in una build di debug, poiché abitualmente includiamo anche il punto e virgola, viene compilato perfettamente. Tuttavia, nella build di rilascio questo si trasforma improvvisamente in:

if( foo )

doSomething();

O più chiaramente formattato

if( foo )
    doSomething();

Che non è affatto ciò che era previsto. L'aggiunta di un do {...} while (false) attorno alla macro trasforma il punto e virgola mancante in un errore di compilazione.

Cosa significa per l'OP?

In generale, si desidera utilizzare le eccezioni in C ++ per la gestione degli errori e i modelli invece delle macro. Tuttavia, nel caso molto raro in cui hai ancora bisogno di macro (ad es. Quando si generano nomi di classi usando il token paste) o sono limitati al semplice C, questo è un modello utile.

Forse è usato in modo che breakpossa essere usato all'interno per interrompere l'esecuzione di ulteriore codice in qualsiasi momento:

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

Penso che questo sia fatto per usare breako continuedichiarazioni. Una sorta di logica del codice "goto".

È semplice: a quanto pare puoi uscire dal falso loop in qualsiasi momento usando l' breakaffermazione. Inoltre, il doblocco è un ambito separato (che potrebbe anche essere ottenuto { ... }solo con ).

In una situazione del genere, potrebbe essere un'idea migliore usare RAII (oggetti che si distruggono automaticamente correttamente quando la funzione termina). Un altro costrutto simile è l'uso di goto- sì, lo so che è malvagio , ma può essere usato per avere un codice di pulizia comune in questo modo:

<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>
}

(Per inciso: il costrutto do-while-false è usato in Lua per trovare l' continueaffermazione mancante .)

Molti rispondenti hanno spiegato il motivo do{(...)break;}while(false). Vorrei completare l'immagine con un altro esempio di vita reale.

Nel codice seguente ho dovuto impostare l'enumeratore in operationbase all'indirizzo puntato dal datapuntatore. Poiché uno switch-case può essere utilizzato solo su tipi scalari prima l'ho fatto in modo inefficiente in questo modo

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

Log("operation:",operation);

Ma poiché Log () e il resto del codice si ripetono per qualsiasi valore di operazione scelto, stavo vagando su come saltare il resto dei confronti quando l'indirizzo è stato già scoperto. Ed è qui che do{(...)break;}while(false)torna utile.

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);

Ci si potrebbe chiedere perché non ha potuto fare lo stesso con breakuna ifdichiarazione, come:

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

breakinteragisce esclusivamente con il loop o l'interruttore che lo racchiude più vicino , sia esso a for, whileo do .. whiletype, quindi sfortunatamente non funzionerà.

Quanti anni aveva l'autore?

Lo chiedo perché una volta mi sono imbattuto in un codice Fortran in tempo reale che lo ha fatto, alla fine degli anni '80. Si scopre che è un ottimo modo per simulare i thread su un sistema operativo che non li ha. Devi solo mettere l'intero programma (il tuo scheduler) in un ciclo e chiamare le tue routine "thread" "una per una. Le routine dei thread stesse sono cicli che ripetono fino a quando non si verifica una delle numerose condizioni (spesso una è una certa quantità di tempo è passato). È "multitasking cooperativo", in quanto spetta ai singoli thread rinunciare alla CPU ogni tanto in modo che gli altri non vengano affamati. Puoi annidare le chiamate di sottoprogramma in loop per simulare la priorità del thread bande.

Oltre ai già citati "goto examples", l'idioma do ... una chiamata macro.

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

Sono d'accordo con la maggior parte dei poster sull'utilizzo come goto sottilmente camuffato. Le macro sono state anche menzionate come potenziale motivazione per scrivere codice nello stile.

Ho anche visto questo costrutto utilizzato in ambienti misti C / C ++ come un'eccezione per i poveri. Il "do {} while (false)" con un "break" può essere usato per saltare alla fine del blocco di codice nel caso in cui qualcosa che normalmente dovrebbe giustificare un'eccezione si incontra nel ciclo.

Ho anche sentito questo costrutto utilizzato nei negozi dove viene applicata l'ideologia del "rendimento unico per funzione". Ancora una volta, questo è al posto di un "goto" esplicito, ma la motivazione è di evitare più punti di ritorno, non di "saltare" il codice e continuare l'esecuzione effettiva all'interno di quella funzione.

Lavoro con Adobe InDesign SDK e gli esempi di InDesign SDK hanno quasi tutte le funzioni scritte in questo modo. È dovuto al fatto che le funzioni sono solitamente molto lunghe. Dove è necessario eseguire QueryInterface (...) per ottenere qualsiasi cosa dal modello a oggetti dell'applicazione. Quindi di solito ogni QueryInterface è seguita da ifnot gone well, break.

Molti hanno già affermato la somiglianza tra questo costrutto e a goto, e hanno espresso una preferenza per il goto. Forse il background di questa persona includeva un ambiente in cui i goto erano severamente vietati dalle linee guida di codifica?

L'altro motivo che mi viene in mente è che decora le parentesi graffe, mentre io credo in un nuovo standard C ++ le parentesi graffe nude non vanno bene (ISO C non le piacciono). Altrimenti per silenziare un analizzatore statico come lanugine.

Non sono sicuro del motivo per cui li vorresti, forse portata variabile o vantaggio con un debugger.

Vedere Trivial Do While loop e Braces are Good from C2.

Per chiarire la mia terminologia (che credo segua l'uso standard):

Bretelle nude :

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

Parentesi graffe vuote (NOP):

{}

per esempio

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

Blocco :

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

che diventerebbe

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

se le parentesi graffe vengono rimosse, alterando così il flusso di esecuzione, non solo l'ambito delle variabili locali. Quindi non "indipendente" o "nudo".

Le parentesi graffe nude o un blocco possono essere utilizzati per indicare qualsiasi sezione di codice che potrebbe essere un potenziale per una funzione (inline) che si desidera contrassegnare, ma non refactoring in quel momento.

È un modo artificioso per emulare un GOTOdato che questi due sono praticamente identici:

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

e:

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

D'altra parte, entrambi dovrebbero essere fatti con ifs:

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

Anche se l'annidamento può diventare un po 'brutto se si trasforma semplicemente una lunga stringa di forward GOTOin ifs annidati . La vera risposta è un corretto refactoring, non imitando i costrutti linguistici arcaici.

Se stavi cercando disperatamente di traslitterare un algoritmo contenente GOTOs, probabilmente potresti farlo con questo idioma. Tuttavia, è certamente non standard e un buon indicatore del fatto che non stai aderendo strettamente agli idiomi previsti per la lingua.

Non sono a conoscenza di alcun linguaggio simile al C in cui do / while è una soluzione idiomatica per qualsiasi cosa, in realtà.

Probabilmente potresti rifattorizzare l'intero pasticcio in qualcosa di più sensato per renderlo più idiomatico e molto più leggibile.

Alcuni programmatori preferiscono avere una sola uscita / ritorno dalle loro funzioni. L'uso di un dummy do {....} while (false); ti permette di "rompere" il ciclo fittizio una volta che hai finito e avere ancora un singolo ritorno.

Sono un programmatore Java, quindi il mio esempio sarebbe qualcosa di simile

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;
    }
}

In questi casi utilizzo

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

Questo è divertente. Probabilmente ci sono interruzioni all'interno del ciclo, come altri hanno detto. Lo avrei fatto in questo modo:

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