la meilleure façon de résoudre “la variable 'xxx' a été déclaré mais jamais référencé”
-Pré-condition:
Je sais qu'il a beaucoup de façons d'ignorer cet avertissement, mais je n'ai besoin de le réparer, mais PAS seulement ajouter de certains drapeaux pour le compilateur de l'ignorer, parce que je peux faire ce makefile CFLAG
modification sur mon local, mais la compilation/génération politique ne peuvent PAS été changé en raison de la qualité d'entreprise de contrôle de la raison. À cette question, je veux juste discus qui pour le fixer dans le bon sens mais PAS les ignorer, merci beaucoup!
Pendant ce temps, non SEULEMENT certaines variables ne sont jamais citées, mais aussi il a un avertissement:
function 'xxx' was declared but never referenced
le même problème dans le fichier de tête, il a quelques fonctions statiques, qui n'utiliser que dans un fichier c, mais beaucoup d'autres c des fichiers à inclure ce fichier de tête.
En outre, ce code s'exécute sur un dédier cible, qui a essentiel de la consommation de mémoire, cela signifie que j'ai besoin de prendre soin de chaque bit à la fois dans la mémoire ROM et RAM.
------- Problème montre ci-dessous-----------
Je construis actuellement certains codes, qui fournir par le vendeur et il contient beaucoup de mise en garde, parce que je veux avoir un avertissement de création libre, donc, j'ai mis -Werror
pour gcc
et --diag_error=[error_ref_number]
pour armcc
.
Après ce qui précède makefile modification, la plupart avertissement que j'ai actuellement rencontrer est
variable 'xxx' was declared but never referenced
Il a causé par style de codage suivant:
dans veryBIG.h
, il a défini certaines variables comme l' (juste pour l'exemple, mais le vendeur code est exactement de la même manière):
static const int a = 10;
static const int b = 20;
static const int c = 30;
...
static const int z = xx;
cependant, beaucoup de c des fichiers à inclure cette GROSSE tête de fichier, mais une SEULE de ces c fichier, utilisez l'une des variables ci-dessus, comme a.c
va utiliser la variable a
, b.c
utilisation variable b
, etc,.
Je dois résoudre de deux manières:
-
déplacer ces types de variables dans lui consacrer fichier c, et cela signifie que la tête de fichier de devenir inutile
-
tête séparée fichiers, signifie que j'ai créer
a.h
,b.h
, ...,z.h
, et chaque consacrer fichier c comprennent SEULEMENT l'un des au-dessus de la tête de fichier
Cependant, ces deux moyens de limitation pour mon travail,
Voie 1:
Je ne suis PAS sûr si le vendeur nouvelle mise à jour va changer cette tête de file pour ce qui ou qui ont une mise à jour des valeurs, parce que le vendeur ne voulez PAS pour corriger cette compilation des avertissements, cela signifie que si je suivre la voie 1, je vais mettre à jour manuellement ces variables si elle a été modifiée par le vendeur (UNIQUEMENT en tête de fichier, et je dois synchroniser sur le fichier c) et de cette manière rend mon travail de fusion devenir compliqué
2:
Il a également fait mon travail de fusion deviennent PAS facile, parce que je n'utilise PAS le vendeur et j'ai aussi besoin de modifier le système de fichier makefile pour adapter l'une de ces tête fichiers dans INC
CHEMIN s'ils ne sont PAS localiser dans le même dossier (dont le CHEMIN d'accès déjà définir pour que veryBIG.h
)
Si il une idée pour remédier à ce problème?
Mise à JOUR
Je peux l'utilisation temporaire Wno-xxx
pour gcc
et de supprimer certains [error_ref_number]
drapeau de la --diag_error
(comme CFLAG += --diag_error=550,223,188,177,....,
, et j'ai supprimer 177
pour passer cet avertissement dans armcc
) et rend ma compilation aller sur et fixez d'abord les autres mises en garde, mais je n'ai besoin de réparer TOUS les avertissements.
actuellement non, parce que ce projet QA requis TOUS avertissement gratuit. J'utilise votre façon temporaire, le faire de la compilation se passe et de fixer d'autres premier avertissement, j'utilise
-Wno-unused-variable
pour gcc
et j'ai supprimer certains [error_ref_number]
drapeau de la --diag_error=
pour armcc
Je pense que avertissement gratuit exigence implique la suppression de toutes ces mises en garde qui peut créer des bugs potentiels dans l'avenir. Je ne pense pas que quelques variables supplémentaires allouée de manière statique peut créer problème. Je vous remercie de vos suggestions concernant les scénarios où ils peuvent créer de problème.
Pouvez-vous modifier le fichier d'en-tête pour conditionnellement déclarer ces variables, lorsque certains
MACRO
est défini, Et de définir/annuler la définition même MACRO
C ton fichier avant de l'inclure l'en-tête.Le fait que le programmeur à un moment pensé que ces variables étaient nécessaires, mais finalement n'a pas de référence est un potentiel bug en lui-même. Peut-être du remaniement qui a été fait à mi-chemin, laissant les algorithmes en état instable. Peut-être une faute de frappe dans une macro. En tout cas, c'est une odeur de code.
OriginalL'auteur How Chen | 2014-01-03
Vous devez vous connecter pour publier un commentaire.
Si vous vous souciez de l'utilisation de la mémoire au point où tous les bits questions, alors vous avez probablement devrait briser cet en-tête de fichier en plusieurs petits morceaux, car il n'y a aucune garantie que le compilateur ne émettent chacun de ces
static
des variables et des fonctions dans chaque.c
fichier, même si seulement quelques-uns d'entre eux sont utilisés. (Comme si la règle dit que le compilateur peut supprimer tous les inutilisé statique, mais rien ne dit qu'il a pour.)Dans vos chaussures, je vais probablement écrire une sorte de script qui permettrait de faire automatiquement la rupture; alors je ne voudrais pas avoir à le faire une fois de plus lorsque de nouvelles versions qui s'est passé.
OriginalL'auteur zwol
Autant que je sache, l'avertissement variable 'xxx' a été déclaré mais jamais référencé a PAS de RISQUE à tous pour les appareils modernes. Le seul danger est que la variable peut prendre un peu d'espace de la mémoire lorsque le programme est chargé, même la plus petite des machines modernes ne souffre pas OOM avec juste que peu de la mémoire des déchets. BTW les compilateurs modernes optimisera pour vous, pourquoi ne sont-ils pas puisque le compilateur est déjà en garde de vous en parler. Vous pouvez ignorer l'avertissement.
Si vous trouvez l'avertissement gênant, il suffit d'ajouter la -Wno-unused variable-drapeau lors de la compilation.
Edit: Comme l'a dit Alex dans le commentaire, je suis mal. Mais vous pouvez le voir, que même que peu de risque que je l'ai mentionné, c'est faux. Alors détendez-vous.
Presque tous les projets open source je sais auront non référencées variables, et je ne vois pas un qui fait beaucoup d'efforts pour l'éliminer.
Modifier à Nouveau: Bien, je vois que vous avez besoin absolu d'alerte gratuit. Eh bien, la seule solution je pense, qui nécessite moins d'heures de travail est d'utiliser des #define macros.
Vous faire des blocs de #ifdef/#else/#endif dans votre fichier d'en-tête, et d'ajouter #définit dans votre C fichiers. Mais alors vous avez encore d'utiliser beaucoup de temps à essayer de comprendre les dépendances.
Votre fichier d'en-tête devrait ressembler à quelque chose comme ceci:
et votre A. c fichier devrait ressembler à quelque chose comme ceci:
Que la façon dont le glext.h travaille pour OpenGL. C'est mieux que la rupture dans beaucoup de petits fichiers d'en-tête, comme vous pouvez le voir les dépendances clairement avec les MACROS, tandis que beaucoup de fichiers va vous obliger à faire une bonne documentation. Et les Macros sont plus souples que les fichiers.
Il serait bien si vous pouvez négocier avec le FOURNISSEUR que vous avez mentionné pour eux de toujours vous dire la différence ils ont fait, et il vous suffit de les ajouter à la bonne place. Si vous ne pouvez pas il suffit de garder les histoires de l'original VeryBIG.h et l'utilisation d'un outil de comparaison pour examiner les modifications de la nouvelle.
Oh bon de savoir à ce sujet thx.
cela ne semble pas répondre à l'OP question.
Je ne veux pas les ignorer, j'ai besoin d'avoir un bon moyen pour résoudre ce problème
Je pense que c'est le moyen le plus facile maintenant, merci beaucoup pour votre aide
OriginalL'auteur TwilightSun