54 votes

Identification des codes morts (C++)

J'ai un projet C++ important compilé sous Visual Studio 2008. Je sais qu'il y a une quantité raisonnable de code "mort" qui n'est accessible nulle part - des méthodes qui ne sont pas appelées, des classes entières qui ne sont pas utilisées.

Je suis à la recherche d'un outil qui permettra d'identifier cela en analyse statique .

Cette question : Détection de code mort dans un projet C/C++ existant suggère d'utiliser des outils de couverture de code. Ce n'est pas une option, car la couverture des tests n'est tout simplement pas assez élevée.

Il mentionne également une option -Wunreachable-code. à gcc. J'aimerais quelque chose de similaire pour Visual Studio. Nous utilisons déjà l'option /OPT:REF de l'éditeur de liens pour supprimer le code redondant, mais elle ne signale pas le code mort à un niveau utile (lorsqu'elle est utilisée avec /VERBOSE, il y a plus de 100 000 lignes, y compris beaucoup de bibliothèques).

Existe-t-il de meilleures options qui fonctionnent bien avec un projet Visual Studio ?

0 votes

Nous avons écrit un programme AWK pour analyser ces "100k+ lignes" produites par le linker, et cela nous a permis de voir réellement ce qui se passe. Deux développeurs ont commencé lundi. Vendredi, nous avions un "noyau hérité" fonctionnel.

0voto

Roddy Points 32503

Une approche qui fonctionne pour moi - avec Delphi - consiste à activer le débogage et à exécuter votre programme sous le débogueur.

Lorsqu'un programme Delphi est exécuté sous le débogueur, l'IDE indique dans la marge les lignes de code qui peuvent être définies comme points d'arrêt. Le code qui est vraiment mort - c'est-à-dire qui a été supprimé par l'éditeur de liens/le compilateur - est évident car les points d'arrêt ne peuvent pas être définis à cet endroit.

Quelques notes supplémentaires, car les commentateurs semblent mal comprendre ce point :

a : Vous n'avez pas besoin d'essayer de placer un point d'arrêt sur chaque ligne. Ouvrez simplement le fichier source dans l'IDE et parcourez-le rapidement. Le code mort est facilement repérable.

b : Il ne s'agit PAS d'une vérification de la "couverture du code". Vous n'avez pas besoin d'exécuter l'application pour voir si elle atteint les lignes.

c : Je ne suis pas assez familier avec VS2008 donc je ne peux pas dire si cette suggestion va fonctionner.

0 votes

Bonne idée ! VS n'autorisera pas les points d'arrêt de cette façon dans un build de version ... mais je ne pense pas que cela mette en évidence les lignes affectées visuellement. Vous pourriez regarder la vue mixte assemblage/source pour voir quelles lignes n'ont pas d'assemblage.

0 votes

VS n'autorise pas les points d'arrêt dans le code qui n'est pas "mort", mais désactivé à l'aide de macros. Ainsi, on peut finir par casser certaines macros en supprimant le code apparemment mort. Ceci est dangereux !

0 votes

@Ignas : Et comment, exactement, TOUTE approche va-t-elle régler ce problème ?

-4voto

Écrivez un script qui supprime aléatoirement une fonction (du code source) et recompile tout à partir de zéro. Si cela compile toujours - cette fonction était du code mort.

9 votes

Cela ne fonctionnera pas. Que faire s'il y a une chaîne de 3 fonctions liées, un "cul-de-sac" de code. La suppression de n'importe laquelle de ces fonctions entraînera la rupture de la compilation, même si l'ensemble de ces fonctions est, toutes ensemble, du code mort.

0 votes

Cela fonctionnera dans certains scénarios, et je pense donc que c'est une excellente idée.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X