Dans mon code C++, il m'arrive de temps =E0 autres de faire une erreur
b=EAte de copier-coller et d'avoir (typiquement) deux boucles imbriqu=E9es
qui utilisent involontairement le m=EAme indice (par exemple parce que
j'ai copi=E9 la boucle interne d'un autre endroit du code et que j'ai
oubli=E9 de changer son indice), genre :
for (int i =3D 0; i < n; ++i) {
...
for (int i =3D 0; i < m; ++i) { // Oops, it's supposed to be j
here !
...
}
}
Je me dis que g++ devrait =EAtre capable de m'avertir de ce genre
d'erreurs, parce que =E7a me semble quand m=EAme =EAtre une construction qui=
doit =EAtre une erreur du programmeur dans la tr=E8s grande majorit=E9 des
cas, et que =E7a ne me semble pas tr=E8s difficile =E0 d=E9tecter.
Mais j'ai cherch=E9 rapidement (peut-=EAtre trop...) dans le man de g++,
sans trouver de flag qui permette de forcer un warning dans des cas
comme =E7a. J'ai mal cherch=E9 ou =E7a existe pas ?
Dans mon code C++, il m'arrive de temps à autres de faire une erreur bête de copier-coller et d'avoir (typiquement) deux boucles imbriquées qui utilisent involontairement le même indice (par exemple parce que j'ai copié la boucle interne d'un autre endroit du code et que j'ai oublié de changer son indice), genre :
for (int i = 0; i < n; ++i) { ... for (int i = 0; i < m; ++i) { // Oops, it's supposed to be j here ! ... } }
Je me dis que g++ devrait être capable de m'avertir de ce genre d'erreurs, parce que ça me semble quand même être une construction qui doit être une erreur du programmeur dans la très grande majorité des cas, et que ça ne me semble pas très difficile à détecter.
L'option '-Wshadow' fait exactement cela... J'étais persuadé qu'elle était activée par '-Wall' mais ce n'est pas le cas.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Dans mon code C++, il m'arrive de temps à autres de faire une erreur
bête de copier-coller et d'avoir (typiquement) deux boucles imbriquées
qui utilisent involontairement le même indice (par exemple parce que
j'ai copié la boucle interne d'un autre endroit du code et que j'ai
oublié de changer son indice), genre :
for (int i = 0; i < n; ++i) {
...
for (int i = 0; i < m; ++i) { // Oops, it's supposed to be j
here !
...
}
}
Je me dis que g++ devrait être capable de m'avertir de ce genre
d'erreurs, parce que ça me semble quand même être une construction qui
doit être une erreur du programmeur dans la très grande majorité des
cas, et que ça ne me semble pas très difficile à détecter.
L'option '-Wshadow' fait exactement cela... J'étais persuadé qu'elle
était activée par '-Wall' mais ce n'est pas le cas.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Dans mon code C++, il m'arrive de temps à autres de faire une erreur bête de copier-coller et d'avoir (typiquement) deux boucles imbriquées qui utilisent involontairement le même indice (par exemple parce que j'ai copié la boucle interne d'un autre endroit du code et que j'ai oublié de changer son indice), genre :
for (int i = 0; i < n; ++i) { ... for (int i = 0; i < m; ++i) { // Oops, it's supposed to be j here ! ... } }
Je me dis que g++ devrait être capable de m'avertir de ce genre d'erreurs, parce que ça me semble quand même être une construction qui doit être une erreur du programmeur dans la très grande majorité des cas, et que ça ne me semble pas très difficile à détecter.
L'option '-Wshadow' fait exactement cela... J'étais persuadé qu'elle était activée par '-Wall' mais ce n'est pas le cas.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Rémi Moyen
On Apr 4, 11:08 am, Paul Gaborit wrote:
Dans mon code C++, il m'arrive de temps à autres de faire une erreur bête de copier-coller et d'avoir (typiquement) deux boucles imbriqué es qui utilisent involontairement le même indice
L'option '-Wshadow' fait exactement cela...
Super, c'est bien ça ! J'avais cherché dans le man avec des trucs autour de "hide", "overload", "redefine", j'avais pas pensé à "shadow".
J'étais persuadé qu'elle était activée par '-Wall' mais ce n'est pas le cas.
Oui, c'est aussi ce que je me suis dit au début et j'ai été surpris que ce ne soit pas le cas !
Histoire d'élargir un peu la discussion, quels sont vos warnings "préférés" que vous ajoutez fréquemment (ou systématiquement) ?
En tout cas, merci pour ta réponse rapide. -- Rémi Moyen
On Apr 4, 11:08 am, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
Dans mon code C++, il m'arrive de temps à autres de faire une erreur
bête de copier-coller et d'avoir (typiquement) deux boucles imbriqué es
qui utilisent involontairement le même indice
L'option '-Wshadow' fait exactement cela...
Super, c'est bien ça ! J'avais cherché dans le man avec des trucs
autour de "hide", "overload", "redefine", j'avais pas pensé à
"shadow".
J'étais persuadé qu'elle
était activée par '-Wall' mais ce n'est pas le cas.
Oui, c'est aussi ce que je me suis dit au début et j'ai été surpris
que ce ne soit pas le cas !
Histoire d'élargir un peu la discussion, quels sont vos warnings
"préférés" que vous ajoutez fréquemment (ou systématiquement) ?
En tout cas, merci pour ta réponse rapide.
--
Rémi Moyen
Dans mon code C++, il m'arrive de temps à autres de faire une erreur bête de copier-coller et d'avoir (typiquement) deux boucles imbriqué es qui utilisent involontairement le même indice
L'option '-Wshadow' fait exactement cela...
Super, c'est bien ça ! J'avais cherché dans le man avec des trucs autour de "hide", "overload", "redefine", j'avais pas pensé à "shadow".
J'étais persuadé qu'elle était activée par '-Wall' mais ce n'est pas le cas.
Oui, c'est aussi ce que je me suis dit au début et j'ai été surpris que ce ne soit pas le cas !
Histoire d'élargir un peu la discussion, quels sont vos warnings "préférés" que vous ajoutez fréquemment (ou systématiquement) ?
En tout cas, merci pour ta réponse rapide. -- Rémi Moyen
Histoire d'élargir un peu la discussion, quels sont vos warnings "préférés" que vous ajoutez fréquemment (ou systématiquement) ?
'-Wall' ! ;-)
Aussi -Wextra, vu que « all » ne se traduit pas par « tous » dans la terminologie gcc ;-).
-Wextra non plus d'ailleurs puisque ça n'active toujours pas -Wshadow !
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Thierry B.
--{ Rémi Moyen a plopé ceci: }--
bête de copier-coller
ah...
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
-- $ cat / | od -t a | head -n 3 0000000 stx nul nul nul ff nul soh nul . nul nul nul stx nul nul nul 0000020 ff nul stx nul . . nul nul vt nul nul nul dc4 nul nl nul 0000040 l o s t + f o u n d nul nul O eot nul nul
--{ Rémi Moyen a plopé ceci: }--
bête de copier-coller
ah...
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
--
$ cat / | od -t a | head -n 3
0000000 stx nul nul nul ff nul soh nul . nul nul nul stx nul nul nul
0000020 ff nul stx nul . . nul nul vt nul nul nul dc4 nul nl nul
0000040 l o s t + f o u n d nul nul O eot nul nul
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
-- $ cat / | od -t a | head -n 3 0000000 stx nul nul nul ff nul soh nul . nul nul nul stx nul nul nul 0000020 ff nul stx nul . . nul nul vt nul nul nul dc4 nul nl nul 0000040 l o s t + f o u n d nul nul O eot nul nul
Rémi Moyen
On Apr 4, 1:12 pm, "Thierry B." wrote:
--{ Rémi Moyen a plopé ceci: }--
bête de copier-coller
ah...
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Peut-être, mais il a -Wshadow qui fait exactement ce que je demande et que certains ont été assez gentils pour m'indiquer. Ce qui est un peu plus utile que de regarder de haut quelqu'un qui a le malheur de faire une erreur (parce que si on commence comme ça, -Wunused et plein d'autres aussi sont inutiles). -- Rémi Moyen
On Apr 4, 1:12 pm, "Thierry B." <t...@prout.stex.invalid> wrote:
--{ Rémi Moyen a plopé ceci: }--
bête de copier-coller
ah...
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Peut-être, mais il a -Wshadow qui fait exactement ce que je demande et
que certains ont été assez gentils pour m'indiquer. Ce qui est un peu
plus utile que de regarder de haut quelqu'un qui a le malheur de faire
une erreur (parce que si on commence comme ça, -Wunused et plein
d'autres aussi sont inutiles).
--
Rémi Moyen
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Peut-être, mais il a -Wshadow qui fait exactement ce que je demande et que certains ont été assez gentils pour m'indiquer. Ce qui est un peu plus utile que de regarder de haut quelqu'un qui a le malheur de faire une erreur (parce que si on commence comme ça, -Wunused et plein d'autres aussi sont inutiles). -- Rémi Moyen
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser plusieurs fois le même nom de variable. Ça peut même arriver sans faire de "bête" copier/coller : par exemple via une macro. C'est donc normal que 'gcc' ne considère pas cela comme une erreur ni même un warning. Ensuite, on peut considérer que ce n'est pas une bonne pratique. D'où l'option -Wshadow...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser
plusieurs fois le même nom de variable. Ça peut même arriver sans
faire de "bête" copier/coller : par exemple via une macro. C'est donc
normal que 'gcc' ne considère pas cela comme une erreur ni même un
warning. Ensuite, on peut considérer que ce n'est pas une bonne
pratique. D'où l'option -Wshadow...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser plusieurs fois le même nom de variable. Ça peut même arriver sans faire de "bête" copier/coller : par exemple via une macro. C'est donc normal que 'gcc' ne considère pas cela comme une erreur ni même un warning. Ensuite, on peut considérer que ce n'est pas une bonne pratique. D'où l'option -Wshadow...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Histoire d'�largir un peu la discussion, quels sont vos warnings "pr�f�r�s" que vous ajoutez fr�quemment (ou syst�matiquement) ?
[Oups, y'en a un de nous deux qui a un problème avec les accents... j'avoue, j'utilise Google Groups depuis le bureau, c'est donc peut- être bien moi.]
Histoire d'�largir un peu la discussion, quels sont vos warnings
"pr�f�r�s" que vous ajoutez fr�quemment (ou syst�matiquement) ?
[Oups, y'en a un de nous deux qui a un problème avec les accents...
j'avoue, j'utilise Google Groups depuis le bureau, c'est donc peut-
être bien moi.]
Histoire d'�largir un peu la discussion, quels sont vos warnings "pr�f�r�s" que vous ajoutez fr�quemment (ou syst�matiquement) ?
[Oups, y'en a un de nous deux qui a un problème avec les accents... j'avoue, j'utilise Google Groups depuis le bureau, c'est donc peut- être bien moi.]
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser plusieurs fois le même nom de variable. Ça peut même arriver sans faire de "bête" copier/coller : par exemple via une macro. C'est donc normal que 'gcc' ne considère pas cela comme une erreur ni même un warning. Ensuite, on peut considérer que ce n'est pas une bonne pratique. D'où l'option -Wshadow...
Tout à fait d'accord.
Au fait, avec le code suivant (non, il ne me semble pas idiot) :
for ( int i=0 ; i<10 ; i++ ) for ( int i=i+1 ; i<10 ; i++ ) printf("%dn",i);
Ca part dans le décor. A mon avis ca ne devrait pas. Le problème vient de l'initalisation (int i=i+1;) dont le i en rhs n'est pas le bon : c'est "le nouveau" qui est pris, pas "l'ancien". Dommage. Dans ce cas, il vaudrait mieux que -Wshadow soit dans -Wall.
-- Alain.
P/S: je vois des adeptes de la programmation fonctionnelle qui rigolent...
Paul Gaborit <Paul.Gaborit@invalid.invalid> writes:
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser
plusieurs fois le même nom de variable. Ça peut même arriver sans
faire de "bête" copier/coller : par exemple via une macro. C'est donc
normal que 'gcc' ne considère pas cela comme une erreur ni même un
warning. Ensuite, on peut considérer que ce n'est pas une bonne
pratique. D'où l'option -Wshadow...
Tout à fait d'accord.
Au fait, avec le code suivant (non, il ne me semble pas idiot) :
for ( int i=0 ; i<10 ; i++ )
for ( int i=i+1 ; i<10 ; i++ )
printf("%dn",i);
Ca part dans le décor. A mon avis ca ne devrait pas. Le problème vient
de l'initalisation (int i=i+1;) dont le i en rhs n'est pas le bon :
c'est "le nouveau" qui est pris, pas "l'ancien". Dommage. Dans ce cas,
il vaudrait mieux que -Wshadow soit dans -Wall.
-- Alain.
P/S: je vois des adeptes de la programmation fonctionnelle qui
rigolent...
Je me dis que g++ devrait être capable de m'avertir de ce genre
gcc n'a pas d'interface avec le neurone des yusers.
Formellement, il n'est ni interdit ni complètement idiot de réutiliser plusieurs fois le même nom de variable. Ça peut même arriver sans faire de "bête" copier/coller : par exemple via une macro. C'est donc normal que 'gcc' ne considère pas cela comme une erreur ni même un warning. Ensuite, on peut considérer que ce n'est pas une bonne pratique. D'où l'option -Wshadow...
Tout à fait d'accord.
Au fait, avec le code suivant (non, il ne me semble pas idiot) :
for ( int i=0 ; i<10 ; i++ ) for ( int i=i+1 ; i<10 ; i++ ) printf("%dn",i);
Ca part dans le décor. A mon avis ca ne devrait pas. Le problème vient de l'initalisation (int i=i+1;) dont le i en rhs n'est pas le bon : c'est "le nouveau" qui est pris, pas "l'ancien". Dommage. Dans ce cas, il vaudrait mieux que -Wshadow soit dans -Wall.
-- Alain.
P/S: je vois des adeptes de la programmation fonctionnelle qui rigolent...
