2015-03-20 1 views
4

J'écris un programme qui est censé résoudre un casse-tête comme sudoko, Hashiwokakero. J'ai un code qui ressemble à ceci:Xcode offre une solution étrange pour le code explicitement mort en C++?

if (bridgesLeft[row][col] == 1) 
{ 
    doSomething(); 
} 
else if (bridgesLeft[row][col] == 2) 
{ 
    doSomethingElse(); 
} 
else if (bridgesLeft[row][col] == 3) 
{ 
    doAnotherThing(); 
} 
... 

je réalisais que je mets un bug dans la fonction doSomethingElse(), donc plutôt que de supprimer ce bloc, j'ai ajouté else if (bridgesLeft[row][col] == 2 && false) pour garantir que la fonction buggy ne fonctionnerait pas, juste pour m'assurer que c'était de là que venait mon insecte. Xcode m'a donné un avertissement, disant que mon code doSomethingElse() ne fonctionnerait jamais. Il m'a aussi donné cette option:

fix-it: Silence by adding parentheses to mark code as explicitly dead. 

En cliquant sur ce bouton change

else if (bridgesLeft[row][col] == 2 && false) 

à

else if (bridgesLeft[row][col] == /* DISABLES CODE */ (2) && false) 

Comment parenthèses autour de la '2' marquer ce code comme explicitement mort? Qu'est-ce que ça veut dire? Si je laisse les parenthèses à l'intérieur, mais que je prends la partie && false, le bloc de code est toujours exécuté, donc il ne fait pas réellement mourir le code.

+0

Le compilateur sait que 'tout est faux && false' et probablement se débarrasser de la quelle partie. Je suppose que cela est plus pertinent si un appel de fonction est cette partie quelle qu'elle soit. Mettre cet appel de fonction entre parenthèses peut indiquer que quelque chose se passe. – usr1234567

+2

Pas une solution, mais peut-être commenter l'appel de la méthode au lieu de jouer avec votre logique. Vous pourriez revenir dans quelques semaines, mois et ne pas savoir pourquoi vous l'avez fait. C'est une bonne pratique de le changer en '// doSomethingElse() temp remove à cause d'un bug dans doSomethingElse'. – vrwim

+0

Personnellement, je désactiverais/ignorerais cet avertissement particulier (au moins dans les versions de débogage), car il n'est PROBABLEMENT pas utile la plupart du temps. Dans les versions "release", où vous êtes censé produire du code "production", il peut être utile de le savoir.Bien que je sois un grand fan de l'activation des avertissements, certains sont plutôt inutiles lorsque vous êtes en train de développer quelque chose (celui que j'ai désactivé est "variable membre inutilisée", car je construis souvent des classes en ajoutant les variables membres sur les fonctions réelles jusqu'à ce que je les contourne pour les implémenter réellement) –

Répondre

4

Cela ne résout pas le problème autant que le silence de l'avertissement en disant clang que le code est censé être mort, nous pouvons voir en lisant Improve -Wunreachable-code to provide a means to indicate code is intentionally marked dead via if((0)) qui dit:

Log: Améliorer -Wunreachable- code pour fournir un moyen d'indiquer le code est intentionnellement marqué mort via if ((0)). En prenant un indice de -Wparentheses, utilisez un extra '()' comme sigil qu'un mort est intentionnellement mort. Par exemple:

if ((0)) { dead } 

Lorsque cette Sigil se trouve, émettons pas un avertissement de code mort. Lorsque l'analyse voit:

if (0) 

suggère encartage '()' comme Fix-It.

D'après ce que je peux dire qu'il est à la recherche d'un littéral dans () entier , qui dans votre cas, le (2) correspond à cette affaire et fait taire l'avertissement.

+0

Hmmm, ne recommanderait-il pas 'if (bridgesLeft [row] [col] == 2 && (false))'? Ne mettrait-il pas les parenthèses autour de la partie qui le rendrait mort? – DJMcMayhem

+0

@DJMcMayhem: J'attendrais 'if ((bridgesLeft [row] [col] == 2) && false)' mais vous pourriez avoir raison aussi. – usr1234567

+0

@DJMcMayhem a mis à jour ma réponse –