Version imprimable
Bonjour,
J'ai un bout de code en C++ compilé avec gcc et des warnings.
Je voudrait supprimer les messages de warning à un endroit particulier du code C++. Mais je ne trouve pas les commande appropriées dy type "#pragma..." qu'ils faut inclure.
Merci de votre aide
Je ne crois pas qu'il y ait d'équivalent à #pragma warning sous gcc: Il n'y a que les options pour désactiver les warnings à l'échelle d'une compilation entière.
Salut,Citation:
Envoyé par uriotcea
Si c'est dans ton code, tu as plutôt intérêt à voir pourquoi ils sont levés et comment les corrigés. Un warning génère souvent un bug ... au moment de la livraison.
Code:
2
3#pragma GCC diagnostic warning "-Wformat"
http://gcc.gnu.org/onlinedocs/gcc/Di...c-Pragmas.html
Mais comme l'a dit 3DArchi, il vaut mieux les résoudre plutôt que les masqué. A moins que ça soit une bibliothèque tiers?
Même si c'est une librarie tiers, je les laisserais.
merci de vos réponses
J'ai des warning sous windows avec ce type de lignes
je ne vois pas moyen de les éviter (pas faute d'avoir essayé)Code:
2
3
4
5
6#ifdef _WIN32 fscanf(f,"%d %I64i %lf ",&n,&N0,&ms); #else fscanf(f,"%d %llu %lf ",&n,&N0,&ms); #endif
maintenant la command
ne semble pas empecher les warningsCode:
2#pragma GCC diagnostic warning "-Wformat"
Et malheureusement j'en ai des centaines.Code:
2
J'ai l'impression d'avoir déjà vu ce bout de code il n'y a pas si longtemps :mrgreen:
Et même la question. Ca frôle le mutlipost à trois mois de distance ;)
Non pas de multipost ici
Aujourd'hui, je m'interroge sur les commandes #pragram et comment supprimer les warnings
Salut,
Déjà, pourquoi utiliser fscanf alors que tu travailles en C++ :question:
Ne pourrais tu pas, tout simplement, utiliser un flux classique et les opérateurs de flux classiques :question:
Sous réserve d'utiliser un flux C++ (parmi ifstream, stringstream,...) tu pourrais te contenter de
qui s'adaptera quoi qu'il arrive au type correspondant aux variables n, NO et ms (y compris s'il s'agit de classes, à ceci près qu'il faudra définir l'opérateur >> pour celles-ci)Code:f>>n>>NO>>ms;
Un lourd passé historique hérité des intervenants précédents :mouarf:Citation:
Envoyé par koala01
Mais, le fait est que, en modifiant les "milliers de lignes de code" (qui, au passage, pourraient en partie du moins être modifiées automatiquement ;)), il s'éviterait bien des soucis par la suite...
Et puis, rien n'empêche d'utiliser les fichiers "C style" à l'écriture et les flux à la lecture, si toutes les écritures sont faites ;) (même si j'admets volontiers que ca n'est pas forcément l'idéal :aie:)
Sur le fond, je partage ton avis : probablement que les lignes seraient déjà remplacées au vue des questions qu'elles ont générées. Mais, après, il n'a peut être pas le choix : question de risque + coût -> + de code modifié = + de risque de bug = couverture de test plus importante = + cher :aie:.Citation:
Envoyé par koala01
Honnetement, je ne crois pas...Citation:
Envoyé par 3DArchi
Les risques sont largement moindre par l'utilisation des flux, ne serait-ce que parce qu'il supprime celui de se tromper de format dans les fprintf fscanf...
En utilisant les flux, tu supprime la compilation conditionnelle selon un ratio minimum de 5 lignes supprimées pour une ligne écrite, ce qui rend le code bien moins complexe
Les tests d'écriture et de leture ne sont au final pas modifié: tu crées une structure donnée, tu l'écris dans le fichier, tu teste la récupération de la structure en lecture ;)
De plus, j'ai du mal à concevoir que cela puisse représenter des "milliers de lignes de code" à modifier: à coup de 6 lignes (la déclaration et l'ouverture du fichier qui devient une déclaration du flux correspondant et les 5 lignes de compilation conditionnelles) à modifier par fonction, de deux fonction par structure, il faudrait déjà arriver à 100 structures à modifier pour arriver seulement à 1200 lignes (qui se transformeraient en 400 lignes de code)
Le risque de problèmes dans un programme tient bien plus de la complexité du code (qui est exponentielle par rapport au nombre d'instructions) que de la modifcation du code...
De ce point de vue, tu limite bien plus les risques en modifiant correctement ton code qu'en ne le le faisant pas ;)
Ok, mon but n'est pas de faire un code super propre pur C++, il conteint du C++ du C du fortran95 et même du fortran77.
Non, actuellement il est robus, presque exent de bug (long long travail de plusieur années) et surtout il est trop utilisé par la communauté (scientifiques) pour que je prennent le risque aujourd'hui de de le remanier completement ou en partie.
Je l'ai optimisé pour enlever tous les warning de maniére à le maintenair plus facilement, il ne me reste que celui que je vous ai indiqué précedemment (des milliers). J'aimerai votre aide pour le retirer le plus proprement possible.
C'est un peu ce que je voulais dire. Quand ça marche, remplacer du code risqué par du code sûr c'est quand même prendre le risque d'une régression. C'est pour ça qu'en général, c'est assez mal vu dans les boîtes. En même temps, c'est dommage car on conserve du code bancal année après année de peur de "faire s'écrouler le château de carte".Citation:
Envoyé par uriotcea
Goten t'a donné (presque) la solution :Citation:
Envoyé par uriotcea
Code:#pragma GCC diagnostic ignored "-Wformat"
Pas de push ou pop sous gcc?
Je n'en n'ai pas vu. C'est effectivement gênant.
Encore heureux que GCC te donne un warning, tu invoques un comportement indéfini.
Ce n'est pas
qu'il faut faire... Le premier cas n'est pas à utiliser sous win32, mais sous Visual C++.Code:
2
3
4
5
Oui je suis d'accord, je mene des campagne pour réactualiser et moderniser des parties de code régulierement quand ma charge de travail me le permet, mais aujourd'hui ce n'est pas le cas, c'est la raison de ma demande.Citation:
Envoyé par 3DArchi
Oui mais encore, effectivement cela n'a aucun effet et j'ai beau naviguer sur le web, je ne vois pas la syntax nécessaireCitation:
Goten t'a donné (presque) la solution :
En mettant ignored, j'ai bien la disparition du warning.Citation:
Envoyé par uriotcea
Cependant, loufoque a raison :
Il faut que tu changes ta directive de compilation pour modifier selon GCC/Visual et non selon WIN32 ou pas :Citation:
Envoyé par loufoque
Code:
2
3
4
5
6
Tu as tout faux.Citation:
Envoyé par loufoque
Le premier cas est à utiliser sous MinGW, parce qu'il utilise la bibliothèque runtime de Visual 6; ainsi que toute version de Visual strictement inférieure à 8.
En clair, il faudrait plutôt un truc comme ça:
Par contre, même les versions récentes du run-time de Visual ne supportent pas %z pour les types comme size_t. Dans tous les cas, sous Windows, on est obligé d'utiliser %Id ou %Iu.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Ok avec medinoc & 3Darchi
Je suis bien sous minGW avec la runtine6
Et avec "ignored" ca supprime bien les warning
Merci à tous