[C++] Cicli infiniti e cattiva programmazione

[giuscri]

Qualche mese fa un utente del forum mi ha detto che un ciclo infinito è cattiva programmazione. Un altro utente mi ha ricordato che le variabili che servono specificatamente in un solo ciclo andrebbero dichiarate all'interno del ciclo stesso. Adesso vi chiedo: quale codice è preferibile scrivere fra i due seguenti:

//Codice 1

//..

bool uscita = false;

do{

  //corpo

  if(/*condizione*/)
    uscita = true;

}while(uscita != true);

//..

//Codice 2

//..

do{

  bool uscita = false;

  //corpo

  if(/*condizione*/)
    uscita = true;

  if(uscita != false)
    break;

}while(1);

//..

Grazie per l'aiuto -e per l'esperienza messa a disposizione

[nessuno.nobody]

Da vedere è più bello il primo, è più chiaro per chi legge il codice non avendolo scritto (specie se le condizioni sono diverse).
A livello pratico suppongo siano la stessa identica cosa.

[apatriarca]

Personalmente preferisco qualcosa come

do {
    /* ... */
} while (/*condizione*/)

Dipende però da cosa fa il ciclo. Normalmente preferisco usare dei cicli for quando possibile. Ma più che buona o cattiva programmazione, direi che è una questione di stile. Se il significato del codice è evidente, non ha importanza se hai usato o meno un ciclo infinito oppure se le variabili sono dichiarate dentro o fuori dal ciclo o se..

P.S. Dovendo scegliere tra le due versioni che hai scritto.. immagino sceglierei la prima. Non mi sembra molto sensato avere una selezione con un break alla fine di un ciclo quando puoi semplicemente inserire tale condizione tra le parentesi del while.
P.S.2 Nel codice sopra intendo dire che preferisco cercare di eliminare del tutto la variabile di uscita dal ciclo per quanto possibile.

[Deckard1]

Questa è una classica domanda che non potrà mai avere una risposta definitiva; io tendo a concordare con l'opinione (quella più votata del thread) del leggendarioJon Skeet.

[apatriarca]

Bhe.. alla fine è inutile forzare una qualche regola di stile anche quando questa renda la vita più difficile. I goto sono un altro esempio. Nella maggior parte delle situazioni portano a spaghetti code, ma in alcuni casi abbastanza rari portano ad un codice più chiaro (vedi pulizia delle risorse in casi complicati).