Une partie de mon boulot consiste à assurer la maintenance de
quelques applis anciennes dans des environnements pas tous
jeunes (certains clients ont commencé en 2010 à planifier
pour 2012 la migration AIX 4.3 vers AIX 5.2)
Dans le tas, il y a une partie de programmes en C++, qui ont
majoritairement plus de 10 ans, qui n'ont subis depuis que
des corrections ou évolutions mineures.
Comme j'avais un peu de temps, j'ai recompilé pour voir un
de ces progs avec g++ récent (4.4 pour être précis).
Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?) j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)
Je sais parfaitement que le langage a évolué, que les
compilateurs ont progressé, notamment en ce qui concerne
les optimisations, et que certaines constructions jadis
légales sont maintenant dangereuses mais comment repérer
les warnings pertinents dans ce fouillis pour espérer les
corriger ?
Pour parodier un truc connu : trop de warnings tuent les
warnings.
Comment on fait ? On filtre avec grep ? On joue avec
des options ou des pragma ?
Comment on fait ? On filtre avec grep ? On joue avec des options ou des pragma ?
On compile avec -Wall -Wextra -O3 (ou -O2, en tout cas on branche les optimisations, ça permet d'avoir plus de warnings), et si on a la pà ªche on ajoute -pedantic.
Si vraiment ça te fait beaucoup de warnings, utilise un IDE qui parse la sortie du compilo pour te les indiquer dans le source (j'utilise flymake dans emacs, mais j'imagine qu'il doit y avoir d'autres solutions).
Comment on fait ? On filtre avec grep ? On joue avec des options ou
des pragma ?
On compile avec -Wall -Wextra -O3 (ou -O2, en tout cas on branche les
optimisations, ça permet d'avoir plus de warnings), et si on a la pà ªche
on ajoute -pedantic.
Si vraiment ça te fait beaucoup de warnings, utilise un IDE qui parse la
sortie du compilo pour te les indiquer dans le source (j'utilise flymake
dans emacs, mais j'imagine qu'il doit y avoir d'autres solutions).
Comment on fait ? On filtre avec grep ? On joue avec des options ou des pragma ?
On compile avec -Wall -Wextra -O3 (ou -O2, en tout cas on branche les optimisations, ça permet d'avoir plus de warnings), et si on a la pà ªche on ajoute -pedantic.
Si vraiment ça te fait beaucoup de warnings, utilise un IDE qui parse la sortie du compilo pour te les indiquer dans le source (j'utilise flymake dans emacs, mais j'imagine qu'il doit y avoir d'autres solutions).
-- Alain.
Marc
Ronounours wrote:
Une fois passé les premiers obstacles (pourquoi diable j'ai du rajouter des includes de stdio.h, string.h et quelques autres partout alors que précédemment ça passait très bien sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
j'ai des milliers de lignes de warnings abscons deprecated conversion from string constant to 'char*' ou carrément à la con suggest parentheses around '&&' within '||' (je suppose que c'est pour le cas ou le développeur ait du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le passé, on n'a pas le droit d'écrire : char* s="bonjour"; Il faut écrire à la place : const char* s="bonjour"; ou, si on veut écrire dedans ensuite : char s[]="bonjour";
Le second warning me semble être une bonne pratique. Mais on peut toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté de chaque warning l'option correspondante).
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais parfaitement que le langage a évolué, que les compilateurs ont progressé, notamment en ce qui concerne les optimisations, et que certaines constructions jadis légales sont maintenant dangereuses mais comment repérer les warnings pertinents dans ce fouillis pour espérer les corriger ?
On peut faire plus sélectif que -Wall, qui est simplement une bonne base pour la majorité des utilisateurs, mais peut être adapté par chacun.
Ronounours wrote:
Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.
j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le
passé, on n'a pas le droit d'écrire :
char* s="bonjour";
Il faut écrire à la place :
const char* s="bonjour";
ou, si on veut écrire dedans ensuite :
char s[]="bonjour";
Le second warning me semble être une bonne pratique. Mais on peut
toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté
de chaque warning l'option correspondante).
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais parfaitement que le langage a évolué, que les
compilateurs ont progressé, notamment en ce qui concerne
les optimisations, et que certaines constructions jadis
légales sont maintenant dangereuses mais comment repérer
les warnings pertinents dans ce fouillis pour espérer les
corriger ?
On peut faire plus sélectif que -Wall, qui est simplement une bonne
base pour la majorité des utilisateurs, mais peut être adapté par
chacun.
Une fois passé les premiers obstacles (pourquoi diable j'ai du rajouter des includes de stdio.h, string.h et quelques autres partout alors que précédemment ça passait très bien sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
j'ai des milliers de lignes de warnings abscons deprecated conversion from string constant to 'char*' ou carrément à la con suggest parentheses around '&&' within '||' (je suppose que c'est pour le cas ou le développeur ait du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le passé, on n'a pas le droit d'écrire : char* s="bonjour"; Il faut écrire à la place : const char* s="bonjour"; ou, si on veut écrire dedans ensuite : char s[]="bonjour";
Le second warning me semble être une bonne pratique. Mais on peut toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté de chaque warning l'option correspondante).
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais parfaitement que le langage a évolué, que les compilateurs ont progressé, notamment en ce qui concerne les optimisations, et que certaines constructions jadis légales sont maintenant dangereuses mais comment repérer les warnings pertinents dans ce fouillis pour espérer les corriger ?
On peut faire plus sélectif que -Wall, qui est simplement une bonne base pour la majorité des utilisateurs, mais peut être adapté par chacun.
Ronounours
Bonjour,
Le 13/02/2011 21:46, Marc a écrit :
Ronounours wrote:
Une fois passé les premiers obstacles (pourquoi diable j'ai du rajouter des includes de stdio.h, string.h et quelques autres partout alors que précédemment ça passait très bien sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante. Dans mon boulot c'est très important de ne pas casser une configuration qui marche. Mais tant pis, je peux vivre avec.
j'ai des milliers de lignes de warnings abscons deprecated conversion from string constant to 'char*' ou carrément à la con suggest parentheses around '&&' within '||' (je suppose que c'est pour le cas ou le développeur ait du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le passé, on n'a pas le droit d'écrire : char* s="bonjour"; Il faut écrire à la place : const char* s="bonjour"; ou, si on veut écrire dedans ensuite : char s[]="bonjour";
Alors là, merci. Je m'étais tellement polarisé sur deprecated conversion que j'avais même pas une seconde pensé à ça.
Le second warning me semble être une bonne pratique. Mais on peut toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté de chaque warning l'option correspondante).
Et hop, dans le makefile.
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais pas lesquels, peut-être quand on modifie une zone mémoire en utilisant un pointeur ? Des fois qu'il contienne une adresse invalide. On sait jamais.
Et puis aussi au début de chaque compil, un truc du style "vous compilez un programme C++, il pourrait contenir des bugs, vous préférez pas coder en ...." ?
Non, non, les priorités sont définies, et à moins de faire de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Bonjour,
Le 13/02/2011 21:46, Marc a écrit :
Ronounours wrote:
Une fois passé les premiers obstacles (pourquoi diable j'ai
du rajouter des includes de stdio.h, string.h et quelques
autres partout alors que précédemment ça passait très bien
sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante. Dans mon boulot c'est très
important de ne pas casser une configuration qui marche.
Mais tant pis, je peux vivre avec.
j'ai des milliers de lignes de warnings abscons
deprecated conversion from string constant to 'char*'
ou carrément à la con
suggest parentheses around '&&' within '||'
(je suppose que c'est pour le cas ou le développeur ait
du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le
passé, on n'a pas le droit d'écrire :
char* s="bonjour";
Il faut écrire à la place :
const char* s="bonjour";
ou, si on veut écrire dedans ensuite :
char s[]="bonjour";
Alors là, merci. Je m'étais tellement polarisé sur deprecated
conversion que j'avais même pas une seconde pensé à ça.
Le second warning me semble être une bonne pratique. Mais on peut
toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté
de chaque warning l'option correspondante).
Et hop, dans le makefile.
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais pas lesquels, peut-être quand on modifie une zone
mémoire en utilisant un pointeur ? Des fois qu'il contienne
une adresse invalide. On sait jamais.
Et puis aussi au début de chaque compil, un truc du style
"vous compilez un programme C++, il pourrait contenir des
bugs, vous préférez pas coder en ...." ?
Non, non, les priorités sont définies, et à moins de faire
de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Une fois passé les premiers obstacles (pourquoi diable j'ai du rajouter des includes de stdio.h, string.h et quelques autres partout alors que précédemment ça passait très bien sans ?)
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante. Dans mon boulot c'est très important de ne pas casser une configuration qui marche. Mais tant pis, je peux vivre avec.
j'ai des milliers de lignes de warnings abscons deprecated conversion from string constant to 'char*' ou carrément à la con suggest parentheses around '&&' within '||' (je suppose que c'est pour le cas ou le développeur ait du mal avec les règles de priorités)
Le premier warning est assez clair, même si c'était toléré par le passé, on n'a pas le droit d'écrire : char* s="bonjour"; Il faut écrire à la place : const char* s="bonjour"; ou, si on veut écrire dedans ensuite : char s[]="bonjour";
Alors là, merci. Je m'étais tellement polarisé sur deprecated conversion que j'avais même pas une seconde pensé à ça.
Le second warning me semble être une bonne pratique. Mais on peut toujours l'enlever avec -Wno-parentheses (un gcc récent précise à côté de chaque warning l'option correspondante).
Et hop, dans le makefile.
Il y a des warnings beaucoup plus discutables que ces deux-là...
Je sais pas lesquels, peut-être quand on modifie une zone mémoire en utilisant un pointeur ? Des fois qu'il contienne une adresse invalide. On sait jamais.
Et puis aussi au début de chaque compil, un truc du style "vous compilez un programme C++, il pourrait contenir des bugs, vous préférez pas coder en ...." ?
Non, non, les priorités sont définies, et à moins de faire de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Marc
Ronounours wrote:
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante. Dans mon boulot c'est très important de ne pas casser une configuration qui marche.
Il y a des limites à cela. La seule façon de ne rien casser est de ne rien changer. Si ils gardent la compatibilité binaire et qu'il suffit d'ajouter quelques #include évidents pour la compatibilité des sources, ça me semble très acceptable.
Non, non, les priorités sont définies, et à moins de faire de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Je dirais que justement c'est ne pas mettre les parenthèses qui est de l'obfuscated, mais à chaque projet ses conventions.
Ronounours wrote:
Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante. Dans mon boulot c'est très
important de ne pas casser une configuration qui marche.
Il y a des limites à cela. La seule façon de ne rien casser est de ne
rien changer. Si ils gardent la compatibilité binaire et qu'il suffit
d'ajouter quelques #include évidents pour la compatibilité des
sources, ça me semble très acceptable.
Non, non, les priorités sont définies, et à moins de faire
de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Je dirais que justement c'est ne pas mettre les parenthèses qui est de
l'obfuscated, mais à chaque projet ses conventions.
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante. Dans mon boulot c'est très important de ne pas casser une configuration qui marche.
Il y a des limites à cela. La seule façon de ne rien casser est de ne rien changer. Si ils gardent la compatibilité binaire et qu'il suffit d'ajouter quelques #include évidents pour la compatibilité des sources, ça me semble très acceptable.
Non, non, les priorités sont définies, et à moins de faire de l'obfuscated, il n'y a pas besoin de parenthèses inutiles.
Je dirais que justement c'est ne pas mettre les parenthèses qui est de l'obfuscated, mais à chaque projet ses conventions.
Fabien LE LEZ
On Mon, 14 Feb 2011 07:22:54 +0100, Ronounours :
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante.
Le fait pour un code de ne pas inclure les headers dont il a besoin (d'après la norme, pas en essayant au hasard) est un bug. Si une vieille version de g++ acceptait ça, c'était également un bug. Le deuxième bug a été réparé dans g++ ; il ne te reste plus qu'à réparer le premier dans ton code.
On Mon, 14 Feb 2011 07:22:54 +0100, Ronounours :
Parce qu'avant des tas de headers incluaient des tas d'autres headers
inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non
compatibilité ascendante.
Le fait pour un code de ne pas inclure les headers dont il a besoin
(d'après la norme, pas en essayant au hasard) est un bug.
Si une vieille version de g++ acceptait ça, c'était également un bug.
Le deuxième bug a été réparé dans g++ ; il ne te reste plus qu'à
réparer le premier dans ton code.
Parce qu'avant des tas de headers incluaient des tas d'autres headers inutilement, et que quelqu'un a fait le ménage entretemps.
Oui, probablement. ce qui me choque un brin, c'est la non compatibilité ascendante.
Le fait pour un code de ne pas inclure les headers dont il a besoin (d'après la norme, pas en essayant au hasard) est un bug. Si une vieille version de g++ acceptait ça, c'était également un bug. Le deuxième bug a été réparé dans g++ ; il ne te reste plus qu'à réparer le premier dans ton code.
