Quelles sont les meilleures façons d'éviter le do-while (0); pirater en C ++?

Lorsque le flux de code est comme ceci:

if(check())
{
  ...
  ...
  if(check())
  {
    ...
    ...
    if(check())
    {
      ...
      ...
    }
  }
}

J'ai généralement vu ce travail pour éviter le flux de code désordonné ci-dessus:

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

Quelles sont les meilleures façons d'éviter ce contournement / piratage afin qu'il devienne un code de niveau supérieur (niveau industriel)?

Toutes les suggestions qui sont hors de la boîte sont les bienvenues!

Il est considéré comme une pratique acceptable d'isoler ces décisions dans une fonction et d'utiliser returns au lieu de breaks. Bien que toutes ces vérifications correspondent au même niveau d'abstraction que pour la fonction, c'est une approche assez logique.

Par exemple:

void foo(...)
{
   if (!condition)
   {
      return;
   }
   ...
   if (!other condition)
   {
      return;
   }
   ...
   if (!another condition)
   {
      return;
   }
   ... 
   if (!yet another condition)
   {
      return;
   }
   ...
   // Some unconditional stuff       
}

Il y a des moments où utiliser gotoest en fait la bonne réponse - au moins pour ceux qui ne sont pas élevés dans la croyance religieuse qui " gotone peut jamais être la réponse, quelle que soit la question" - et c'est l'un de ces cas.

Ce code utilise le hack de do { ... } while(0);dans le seul but d'habiller un gotocomme un break. Si vous allez utiliser goto, alors soyez ouvert à ce sujet. Il est inutile de rendre le code PLUS DUR à lire.

Une situation particulière se produit juste lorsque vous avez beaucoup de code avec des conditions assez complexes:

void func()
{
   setup of lots of stuff
   ...
   if (condition)
   {
      ... 
      ...
      if (!other condition)
      {
          ...
          if (another condition)
          {
              ... 
              if (yet another condition)
              {
                  ...
                  if (...)
                     ... 
              }
          }
      }
  .... 

  }
  finish up. 
}

Cela peut en fait rendre plus clair que le code est correct en n'ayant pas une logique aussi complexe.

void func()
{
   setup of lots of stuff
   ...
   if (!condition)
   {
      goto finish;
   }
   ... 
   ...
   if (other condition)
   {
      goto finish;
   }
   ...
   if (!another condition)
   {
      goto finish;
   }
   ... 
   if (!yet another condition)
   {
      goto finish;
   }
   ... 
   .... 
   if (...)
         ...    // No need to use goto here. 
 finish:
   finish up. 
}

Edit: Pour clarifier, je ne propose en aucun cas l'utilisation de gotocomme solution générale. Mais il y a des cas où il gotoy a une meilleure solution que d'autres solutions.

Imaginez par exemple que nous collectons des données, et que les différentes conditions testées sont une sorte de "c'est la fin des données collectées" - qui dépend d'une sorte de marqueurs "continuer / terminer" qui varient selon l'endroit vous êtes dans le flux de données.

Maintenant, lorsque nous avons terminé, nous devons enregistrer les données dans un fichier.

Et oui, il existe souvent d'autres solutions qui peuvent fournir une solution raisonnable, mais pas toujours.

Vous pouvez utiliser un modèle de continuation simple avec une boolvariable:

bool goOn;
if ((goOn = check0())) {
    ...
}
if (goOn && (goOn = check1())) {
    ...
}
if (goOn && (goOn = check2())) {
    ...
}
if (goOn && (goOn = check3())) {
    ...
}

Cette chaîne d'exécution s'arrêtera dès que checkNretourne a false. Aucun autre check...()appel ne serait effectué en raison d'un court-circuit de l' &&opérateur. De plus, l'optimisation des compilateurs est suffisamment intelligente pour reconnaître que le réglage goOnsur falseest à sens unique et insérer les éléments manquants goto endpour vous. En conséquence, les performances du code ci-dessus seraient identiques à celles d'un do/ while(0), sans un coup douloureux à sa lisibilité.

1. Essayez d'extraire le code dans une fonction distincte (ou peut-être plus d'une). Revenez ensuite de la fonction si la vérification échoue.

2. S'il est trop étroitement couplé avec le code environnant pour le faire, et que vous ne pouvez pas trouver un moyen de réduire le couplage, regardez le code après ce bloc. Vraisemblablement, il nettoie certaines ressources utilisées par la fonction. Essayez de gérer ces ressources à l'aide d'un objet RAII ; puis remplacez chaque douteux breakpar return(ou throw, si cela est plus approprié) et laissez le destructeur de l'objet nettoyer pour vous.

3. Si le déroulement du programme est (nécessairement) si cahoteux que vous en avez vraiment besoin goto, utilisez-le plutôt que de lui donner un déguisement bizarre.

4. Si vous avez des règles de codage qui l'interdisent aveuglément gotoet que vous ne pouvez vraiment pas simplifier le flux du programme, vous devrez probablement le masquer avec votre dohack.

TLDR : RAII , code transactionnel (définir uniquement les résultats ou renvoyer des éléments lorsqu'ils sont déjà calculés) et exceptions.

Longue réponse:

En C , la meilleure pratique pour ce type de code consiste à ajouter une étiquette EXIT / CLEANUP / other dans le code, où le nettoyage des ressources locales se produit et un code d'erreur (le cas échéant) est renvoyé. C'est la meilleure pratique car elle divise le code naturellement en initialisation, calcul, validation et retour:

error_code_type c_to_refactor(result_type *r)
{
    error_code_type result = error_ok; //error_code_type/error_ok defd. elsewhere
    some_resource r1, r2; // , ...;
    if(error_ok != (result = computation1(&r1))) // Allocates local resources
        goto cleanup;
    if(error_ok != (result = computation2(&r2))) // Allocates local resources
        goto cleanup;
    // ...

    // Commit code: all operations succeeded
    *r = computed_value_n;
cleanup:
    free_resource1(r1);
    free_resource2(r2);
    return result;
}

En C, dans la plupart codebases, le if(error_ok != ...et le gotocode est généralement caché derrière des macros ci ( RET(computation_result), ENSURE_SUCCESS(computation_result, return_code), etc.).

C ++ propose des outils supplémentaires sur C :

• La fonctionnalité de bloc de nettoyage peut être implémentée en tant que RAII, ce qui signifie que vous n'avez plus besoin du cleanupbloc entier et que le code client peut ajouter des instructions de retour anticipées.

• Vous lancez chaque fois que vous ne pouvez pas continuer, transformant tout cela if(error_ok != ...en appels simples.

Code C ++ équivalent:

result_type cpp_code()
{
    raii_resource1 r1 = computation1();
    raii_resource2 r2 = computation2();
    // ...
    return computed_value_n;
}

C'est la meilleure pratique car:

• Il est explicite (c'est-à-dire que si la gestion des erreurs n'est pas explicite, le flux principal de l'algorithme est)

• Il est simple d'écrire du code client

• C'est minime

• C'est simple

• Il n'a pas de constructions de code répétitives

• Il n'utilise pas de macros

• Il n'utilise pas de do { ... } while(0)constructions étranges

• Il est réutilisable avec un minimum d'effort (c'est-à-dire, si je veux copier l'appel vers computation2();une fonction différente, je n'ai pas à m'assurer d'ajouter un do { ... } while(0)dans le nouveau code, ni #defineune macro wrapper goto et une étiquette de nettoyage, ni rien d'autre).

J'ajoute une réponse par souci d'exhaustivité. Un certain nombre d'autres réponses ont souligné que le grand bloc de conditions pouvait être divisé en une fonction distincte. Mais comme cela a également été souligné à plusieurs reprises, cette approche sépare le code conditionnel du contexte d'origine. C'est une des raisons pour lesquelles les lambdas ont été ajoutés au langage en C ++ 11. L'utilisation de lambdas a été suggérée par d'autres, mais aucun échantillon explicite n'a été fourni. J'en ai mis un dans cette réponse. Ce qui me frappe, c'est que cela ressemble beaucoup à l' do { } while(0)approche à bien des égards - et cela signifie peut-être que c'est toujours gotodéguisé ...

earlier operations
...
[&]()->void {

    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
    if (!check()) return;
    ...
    ...
}();
later operations

Certainement pas la réponse, mais une réponse (par souci d'exhaustivité)

Au lieu de :

do {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

Vous pourriez écrire:

switch (0) {
case 0:
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

C'est toujours un goto déguisé, mais au moins ce n'est plus une boucle. Ce qui signifie que vous n'aurez pas à vérifier très attentivement qu'il n'y a pas de poursuite cachée quelque part dans le bloc.

La construction est également assez simple pour que vous puissiez espérer que le compilateur l'optimisera.

Comme suggéré par @jamesdlin, vous pouvez même masquer cela derrière une macro comme

#define BLOC switch(0) case 0:

Et utilisez-le comme

BLOC {
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
}

Cela est possible car la syntaxe du langage C attend une instruction après un commutateur, pas un bloc entre crochets et vous pouvez mettre une étiquette de casse avant cette instruction. Jusqu'à présent, je ne voyais pas l'intérêt de permettre cela, mais dans ce cas particulier, il est pratique de cacher le commutateur derrière une belle macro.

Je recommanderais une approche similaire à la réponse de Mats moins l'inutile goto. Ne mettez que la logique conditionnelle dans la fonction. Tout code qui s'exécute toujours doit aller avant ou après l'appel de la fonction dans l'appelant:

void main()
{
    //do stuff always
    func();
    //do other stuff always
}

void func()
{
    if (!condition)
        return;
    ...
    if (!other condition)
        return;
    ...
    if (!another condition)
        return;
    ... 
    if (!yet another condition)
        return;
    ...
}

Le flux de code lui-même est déjà une odeur de code qui se produit trop dans la fonction. S'il n'y a pas de solution directe à cela (la fonction est une fonction de vérification générale), alors utiliser RAII pour pouvoir revenir au lieu de sauter à la fin d'une section de la fonction pourrait être mieux.

Si vous n'avez pas besoin d'introduire de variables locales pendant l'exécution, vous pouvez souvent aplatir ceci:

if (check()) {
  doStuff();
}  
if (stillOk()) {
  doMoreStuff();
}
if (amIStillReallyOk()) {
  doEvenMore();
}

// edit 
doThingsAtEndAndReportErrorStatus()

Similaire à la réponse de dasblinkenlight, mais évite l'affectation à l'intérieur du ifqui pourrait être «corrigée» par un réviseur de code:

bool goOn = check0();
if (goOn) {
    ...
    goOn = check1();
}
if (goOn) {
    ...
    goOn = check2();
}
if (goOn) {
    ...
}

...

J'utilise ce modèle lorsque les résultats d'une étape doivent être vérifiés avant l'étape suivante, ce qui diffère d'une situation où toutes les vérifications pourraient être effectuées à l'avance avec un if( check1() && check2()...modèle de grand type.

Utilisez des exceptions. Votre code sera beaucoup plus propre (et des exceptions ont été créées exactement pour gérer les erreurs dans le flux d'exécution d'un programme). Pour nettoyer les ressources (descripteurs de fichiers, connexions aux bases de données, etc.), lisez l'article Pourquoi C ++ ne fournit-il pas une construction "enfin"? .

#include <iostream>
#include <stdexcept>   // For exception, runtime_error, out_of_range

int main () {
    try {
        if (!condition)
            throw std::runtime_error("nope.");
        ...
        if (!other condition)
            throw std::runtime_error("nope again.");
        ...
        if (!another condition)
            throw std::runtime_error("told you.");
        ...
        if (!yet another condition)
            throw std::runtime_error("OK, just forget it...");
    }
    catch (std::runtime_error &e) {
        std::cout << e.what() << std::endl;
    }
    catch (...) {
        std::cout << "Caught an unknown exception\n";
    }
    return 0;
}

Pour moi, do{...}while(0)c'est bien. Si vous ne voulez pas voir le do{...}while(0), vous pouvez leur définir des mots-clés alternatifs.

Exemple:

SomeUtilities.hpp:

#define BEGIN_TEST do{
#define END_TEST }while(0);

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) break;
   if(!condition2) break;
   if(!condition3) break;
   if(!condition4) break;
   if(!condition5) break;
   
   //processing code here

END_TEST

Je pense que le compilateur supprimera la while(0)condition inutile do{...}while(0)dans la version binaire et convertira les ruptures en saut inconditionnel. Vous pouvez vérifier sa version en langage assembleur pour en être sûr.

L'utilisation gotoproduit également un code plus propre et c'est simple avec la logique condition-alors-saut. Vous pouvez effectuer les opérations suivantes:

{
   if(!condition1) goto end_blahblah;
   if(!condition2) goto end_blahblah;
   if(!condition3) goto end_blahblah;
   if(!condition4) goto end_blahblah;
   if(!condition5) goto end_blahblah;
   
   //processing code here

 }end_blah_blah:;  //use appropriate label here to describe...
                   //  ...the whole code inside the block.
 

Notez que l'étiquette est placée après la fermeture }. Il s'agit d'éviter un problème possible en gotoplaçant accidentellement un code entre les deux parce que vous n'avez pas vu l'étiquette. C'est maintenant comme do{...}while(0)sans code de condition.

Pour rendre ce code plus propre et plus compréhensible, vous pouvez le faire:

SomeUtilities.hpp:

#define BEGIN_TEST {
#define END_TEST(_test_label_) }_test_label_:;
#define FAILED(_test_label_) goto _test_label_

SomeSourceFile.cpp:

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);
   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);
   if(!condition5) FAILED(NormalizeData);

END_TEST(NormalizeData)

Avec cela, vous pouvez faire des blocs imbriqués et spécifier où vous souhaitez quitter / sauter.

BEGIN_TEST
   if(!condition1) FAILED(NormalizeData);
   if(!condition2) FAILED(NormalizeData);

   BEGIN_TEST
      if(!conditionAA) FAILED(DecryptBlah);
      if(!conditionBB) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionCC) FAILED(DecryptBlah);
  
      // --We can now decrypt and do other stuffs.

   END_TEST(DecryptBlah)

   if(!condition3) FAILED(NormalizeData);
   if(!condition4) FAILED(NormalizeData);

   // --other code here

   BEGIN_TEST
      if(!conditionA) FAILED(TrimSpaces);
      if(!conditionB) FAILED(TrimSpaces);
      if(!conditionC) FAILED(NormalizeData);   //Jump out to the outmost block
      if(!conditionD) FAILED(TrimSpaces);

      // --We can now trim completely or do other stuffs.

   END_TEST(TrimSpaces)

   // --Other code here...

   if(!condition5) FAILED(NormalizeData);

   //Ok, we got here. We can now process what we need to process.

END_TEST(NormalizeData)

Le code spaghetti n'est pas la faute de goto, c'est la faute du programmeur. Vous pouvez toujours produire du code spaghetti sans utiliser goto.

C'est un problème bien connu et bien résolu du point de vue de la programmation fonctionnelle - peut-être la monade.

En réponse au commentaire que j'ai reçu ci-dessous, j'ai édité mon introduction ici: Vous pouvez trouver tous les détails sur la mise en œuvre des monades C ++ dans divers endroits qui vous permettront de réaliser ce que Rotsor suggère. Il faut du temps pour grogner des monades, donc je vais suggérer ici un mécanisme de type monade "pauvre" pour lequel vous n'avez besoin de rien savoir de plus que boost :: optional.

Configurez vos étapes de calcul comme suit:

boost::optional<EnabledContext> enabled(boost::optional<Context> context);
boost::optional<EnergisedContext> energised(boost::optional<EnabledContext> context);

Chaque étape de calcul peut évidemment faire quelque chose comme return boost::nonesi l'option facultative qui lui a été donnée est vide. Ainsi, par exemple:

struct Context { std::string coordinates_filename; /* ... */ };

struct EnabledContext { int x; int y; int z; /* ... */ };

boost::optional<EnabledContext> enabled(boost::optional<Context> c) {
   if (!c) return boost::none; // this line becomes implicit if going the whole hog with monads
   if (!exists((*c).coordinates_filename)) return boost::none; // return none when any error is encountered.
   EnabledContext ec;
   std::ifstream file_in((*c).coordinates_filename.c_str());
   file_in >> ec.x >> ec.y >> ec.z;
   return boost::optional<EnabledContext>(ec); // All ok. Return non-empty value.
}

Ensuite, enchaînez-les:

Context context("planet_surface.txt", ...); // Close over all needed bits and pieces

boost::optional<EnergisedContext> result(energised(enabled(context)));
if (result) { // A single level "if" statement
    // do work on *result
} else {
    // error
}

La bonne chose à ce sujet est que vous pouvez écrire des tests unitaires clairement définis pour chaque étape de calcul. L'invocation se lit également comme un anglais simple (comme c'est généralement le cas avec le style fonctionnel).

Si vous ne vous souciez pas de l'immuabilité et qu'il est plus pratique de renvoyer le même objet à chaque fois que vous pouvez proposer une variation en utilisant shared_ptr ou similaire.

Que diriez-vous de déplacer les instructions if dans une fonction supplémentaire produisant un résultat numérique ou enum?

int ConditionCode (void) {
   if (condition1)
      return 1;
   if (condition2)
      return 2;
   ...
   return 0;
}


void MyFunc (void) {
   switch (ConditionCode ()) {
      case 1:
         ...
         break;

      case 2:
         ...
         break;

      ...

      default:
         ...
         break;
   }
}

Quelque chose comme ça peut-être

#define EVER ;;

for(EVER)
{
    if(!check()) break;
}

ou utiliser des exceptions

try
{
    for(;;)
        if(!check()) throw 1;
}
catch()
{
}

En utilisant des exceptions, vous pouvez également transmettre des données.

Je ne suis pas particulièrement intéressé par l'utilisation breakoureturn dans un tel cas. Étant donné que normalement, lorsque nous sommes confrontés à une telle situation, il s'agit généralement d'une méthode relativement longue.

Si nous avons plusieurs points de sortie, cela peut causer des difficultés lorsque nous voulons savoir ce qui entraînera l'exécution de certaines logiques: normalement, nous continuons à monter des blocs enfermant ce morceau de logique, et les critères de ces blocs renfermant nous indiquent la situation:

Par exemple,

if (conditionA) {
    ....
    if (conditionB) {
        ....
        if (conditionC) {
            myLogic();
        }
    }
}

En regardant les blocs englobants, il est facile de découvrir que cela myLogic()ne se produit que lorsque conditionA and conditionB and conditionCc'est vrai.

Cela devient beaucoup moins visible lorsqu'il y a des retours précoces:

if (conditionA) {
    ....
    if (!conditionB) {
        return;
    }
    if (!conditionD) {
        return;
    }
    if (conditionC) {
        myLogic();
    }
}

Nous ne pouvons plus naviguer vers le haut myLogic(), en regardant le bloc englobant pour comprendre la condition.

Il existe différentes solutions de contournement que j'ai utilisées. Voici l'un d'entre eux:

if (conditionA) {
    isA = true;
    ....
}

if (isA && conditionB) {
    isB = true;
    ...
}

if (isB && conditionC) {
    isC = true;
    myLogic();
}

(Bien sûr, il est recommandé d'utiliser la même variable pour remplacer tous les isA isB isC .)

Une telle approche donnera au moins au lecteur de code, qui myLogic()est exécuté quand isB && conditionC. Le lecteur reçoit un indice qu'il a besoin de rechercher plus loin ce qui fera que isB soit vrai.

typedef bool (*Checker)();

Checker * checkers[]={
 &checker0,&checker1,.....，&checkerN,NULL
};

bool checker1(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

bool checker2(){
  if(condition){
    .....
    .....
    return true;
  }
  return false;
}

......

void doCheck(){
  Checker ** checker = checkers;
  while( *checker && (*checker)())
    checker++;
}

Et ça?

Un autre modèle utile si vous avez besoin de différentes étapes de nettoyage en fonction de l'emplacement de l'échec:

    private ResultCode DoEverything()
    {
        ResultCode processResult = ResultCode.FAILURE;
        if (DoStep1() != ResultCode.SUCCESSFUL)
        {
            Step1FailureCleanup();
        }
        else if (DoStep2() != ResultCode.SUCCESSFUL)
        {
            Step2FailureCleanup();
            processResult = ResultCode.SPECIFIC_FAILURE;
        }
        else if (DoStep3() != ResultCode.SUCCESSFUL)
        {
            Step3FailureCleanup();
        }
        ...
        else
        {
            processResult = ResultCode.SUCCESSFUL;
        }
        return processResult;
    }

Je ne suis pas un programmeur C ++ , donc je n'écrirai aucun code ici, mais jusqu'à présent, personne n'a mentionné de solution orientée objet. Voici donc ma supposition à ce sujet:

Avoir une interface générique qui fournit une méthode pour évaluer une seule condition. Vous pouvez maintenant utiliser une liste d'implémentations de ces conditions dans votre objet contenant la méthode en question. Vous parcourez la liste et évaluez chaque condition, pouvant éventuellement survenir tôt en cas d'échec.

La bonne chose est qu'une telle conception adhère très bien au principe ouvert / fermé , car vous pouvez facilement ajouter de nouvelles conditions lors de l'initialisation de l'objet contenant la méthode en question. Vous pouvez même ajouter une deuxième méthode à l'interface avec la méthode d'évaluation des conditions renvoyant une description de la condition. Cela peut être utilisé pour les systèmes d'auto-documentation.

L'inconvénient, cependant, est qu'il y a un peu plus de frais généraux impliqués en raison de l'utilisation de plus d'objets et de l'itération sur la liste.

C'est ainsi que je le fais.

void func() {
  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...

  if (!check()) return;
  ...
  ...
}

Tout d'abord, un petit exemple pour montrer pourquoi ce goton'est pas une bonne solution pour C ++:

struct Bar {
    Bar();
};

extern bool check();

void foo()
{
    if (!check())
       goto out;

    Bar x;

    out:
}

Essayez de compiler cela dans un fichier objet et voyez ce qui se passe. Essayez ensuite l'équivalent do+ break+while(0) .

C'était un aparté. Le point principal suit.

Ces petits morceaux de code nécessitent souvent une sorte de nettoyage si la fonction entière échoue. Ces nettoyages veulent généralement se produire dans l' ordre inverse des morceaux eux-mêmes, lorsque vous "déroulez" le calcul partiellement terminé.

Une option pour obtenir cette sémantique est RAII ; voir la réponse de @ utnapistim. C ++ garantit que les destructeurs automatiques fonctionnent dans l'ordre inverse des constructeurs, ce qui fournit naturellement un "déroulement".

Mais cela nécessite beaucoup de classes RAII. Parfois, une option plus simple consiste simplement à utiliser la pile:

bool calc1()
{
    if (!check())
        return false;

    // ... Do stuff1 here ...

    if (!calc2()) {
        // ... Undo stuff1 here ...
        return false;
    }

    return true;
}

bool calc2()
{
    if (!check())
        return false;

    // ... Do stuff2 here ...

    if (!calc3()) {
        // ... Undo stuff2 here ...
        return false;
    }

    return true;
}

...etc. Ceci est facile à auditer, car il place le code "annuler" à côté du code "faire". Un audit facile est bon. Cela rend également le flux de contrôle très clair. C'est aussi un modèle utile pour C.

Cela peut nécessiter que les calcfonctions prennent beaucoup d'arguments, mais ce n'est généralement pas un problème si vos classes / structures ont une bonne cohésion. (C'est-à-dire que les choses qui appartiennent ensemble vivent dans un seul objet, de sorte que ces fonctions peuvent prendre des pointeurs ou des références à un petit nombre d'objets tout en faisant beaucoup de travail utile.)

Si votre code contient un long bloc d'instructions if..else if..else, vous pouvez essayer de réécrire le bloc entier à l'aide de Functorsou function pointers. Ce n'est peut-être pas toujours la bonne solution, mais c'est souvent le cas.

http://www.cprogramming.com/tutorial/functors-function-objects-in-c++.html

Je suis étonné du nombre de réponses différentes présentées ici. Mais, finalement, dans le code que je dois changer (c'est-à-dire supprimer ce do-while(0)hack ou quoi que ce soit), j'ai fait quelque chose de différent de toutes les réponses mentionnées ici et je ne comprends pas pourquoi personne ne pensait cela. Voici ce que j'ai fait:

Code initial:

do {

    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
    if(!check()) break;
    ...
    ...
} while(0);

finishingUpStuff.

Maintenant:

finish(params)
{
  ...
  ...
}

if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...
if(!check()){
    finish(params);    
    return;
}
...
...

Donc, ce qui a été fait ici, c'est que la finition a été isolée dans une fonction et que les choses sont soudainement devenues si simples et propres!

Je pensais que cette solution méritait d'être mentionnée, alors je l'ai fournie ici.

Consolidez-le en une seule ifdéclaration:

if(
    condition
    && other_condition
    && another_condition
    && yet_another_condition
    && ...
) {
        if (final_cond){
            //Do stuff
        } else {
            //Do other stuff
        }
}

Il s'agit du modèle utilisé dans des langages tels que Java où le mot-clé goto a été supprimé.

Si vous utilisez le même gestionnaire d'erreurs pour toutes les erreurs et que chaque étape renvoie un booléen indiquant la réussite:

if(
    DoSomething() &&
    DoSomethingElse() &&
    DoAThirdThing() )
{
    // do good condition action
}
else
{
    // handle error
}

(Similaire à la réponse de tyzoid, mais les conditions sont les actions, et le && empêche des actions supplémentaires de se produire après le premier échec.)

Pourquoi n'a-t-on pas répondu à la méthode de signalisation, elle est utilisée depuis des siècles.

//you can use something like this (pseudocode)
long var = 0;
if(condition)  flag a bit in var
if(condition)  flag another bit in var
if(condition)  flag another bit in var
............
if(var == certain number) {
Do the required task
}