Voici donc ce qui devrait arriver dans les pages de man.
Par rapport à ce que nous avions proposé, les parties "WARNING"
et "BUG" ont été oublié, pour ne reprendre que la description
de ce qu'elles font, pas les mises en garde.
DESCRIPTION
The strcat() function appends the src string to the dest
string, overwriting the null character (`\0') at the end of
dest, and then adds a terminating null character. The
strings may not overlap, and the dest string must have
enough space for the result.
The strncat() function is similar, except that
* it will use at most n characters from src; and
* src does not need to be null terminated if it contains n
or more characters.
As with strcat(), the resulting string in dest is always
null terminated.
If src contains n or more characters, strcat() writes n+1
characters to dest (n from src plus the terminating null
character). Therefore, the size of dest must be at least
strlen(dest)+n+1.
Pour ma part, beaucoup plus simplement, quand il y a un paramètre inutile dans une signature, je change la signature.
C'est ce qui se passe dans 90% du temps. Les autres cas sont lies a des pointeurs sur fonction ce qui fait que l'appelant ne sait pas que le parametre est inutile.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Le 20-06-2007, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
Pour ma part, beaucoup plus simplement, quand il y a un paramètre
inutile dans une signature, je change la signature.
C'est ce qui se passe dans 90% du temps. Les autres cas sont lies a des
pointeurs sur fonction ce qui fait que l'appelant ne sait pas que le
parametre est inutile.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Pour ma part, beaucoup plus simplement, quand il y a un paramètre inutile dans une signature, je change la signature.
C'est ce qui se passe dans 90% du temps. Les autres cas sont lies a des pointeurs sur fonction ce qui fait que l'appelant ne sait pas que le parametre est inutile.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Le 20-06-2007, Gabriel Dos Reis a écrit :
Marc Boyer writes: | >| > Je laisse le compilateur raler -- c'est une limitation stupide du langage. | >| > | >| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais | >| > je ne l'ecris pas dans mes propres codes. | >| | >| Sauf que cet __attributte__ est spécifique à GCC non ? | >| Alors que le (void) est plus populaire, pour un résultat | >| semblable, non ? | > | > Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code | > populaire. J'essaie d'ecrire du code simple, correcte, lisible et | > maintenable. (Je n'y arrive pas toujours, mais j'essaie). | | Pour ma part, beaucoup plus simplement, quand il y a un paramètre | inutile dans une signature, je change la signature.
Cela n'est pas toujours possible -- ou alors, possible mais avec encore plus de monstruosites. Par exemple, considere le cas des frameworks ou des callbacks. Le type des functions est fige par le concepteur du framework, et les arguments passes aux callbacks ne sont pas forcement utilises.
Oui.
| Mais il semble que dans l'industrie, une fois qu'on a fixé une | interface, on répugne à la faire bouger.
Cela n'est pas seulement de la repugnance -- et on n'a pas forcement besoin d'aller dans l'industrie pour trouver cela, bien que l'industrie est plus grande productrice et consomatrice de frameworks.
ok
| Donc, on a ces 'unused parameters'. Qu'en fait-on ?
Comme je l'ai observe plus tot, soit on change de langage,
Sur un autre forum alors.
soit on laisse le warning car c'est un cas legitime ou le warning n'est le que le reflet d'une limitation stupide du langage.
Ca, que le langage soit imparfait, nous sommes d'accord. Mais si cela génère une dizaine de warning à chaque compilation, et si le programmeur me ressemble, au bout d'un moment, il s'habitue à ces dix warning, et le jour où un onzième apparaît, il ne le voit pas, alors que celui là était peut-être utile.
Mutiler le code (avec ou sans commentaire) ne fait qu'empirer une situation deja pas rose, si tu veux mon avis.
Ben, je ne vois pas en quoi c'est une mutilation.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 20-06-2007, Gabriel Dos Reis <gdr@integrable-solutions.net> a écrit :
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >| > Je laisse le compilateur raler -- c'est une limitation stupide du langage.
| >| >
| >| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais
| >| > je ne l'ecris pas dans mes propres codes.
| >|
| >| Sauf que cet __attributte__ est spécifique à GCC non ?
| >| Alors que le (void) est plus populaire, pour un résultat
| >| semblable, non ?
| >
| > Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code
| > populaire. J'essaie d'ecrire du code simple, correcte, lisible et
| > maintenable. (Je n'y arrive pas toujours, mais j'essaie).
|
| Pour ma part, beaucoup plus simplement, quand il y a un paramètre
| inutile dans une signature, je change la signature.
Cela n'est pas toujours possible -- ou alors, possible mais avec
encore plus de monstruosites. Par exemple, considere le cas des
frameworks ou des callbacks. Le type des functions est fige par
le concepteur du framework, et les arguments passes aux callbacks ne
sont pas forcement utilises.
Oui.
| Mais il semble que dans l'industrie, une fois qu'on a fixé une
| interface, on répugne à la faire bouger.
Cela n'est pas seulement de la repugnance -- et on n'a pas forcement
besoin d'aller dans l'industrie pour trouver cela, bien que
l'industrie est plus grande productrice et consomatrice de frameworks.
ok
| Donc, on a ces 'unused parameters'. Qu'en fait-on ?
Comme je l'ai observe plus tot, soit on change de langage,
Sur un autre forum alors.
soit on
laisse le warning car c'est un cas legitime ou le warning n'est le que
le reflet d'une limitation stupide du langage.
Ca, que le langage soit imparfait, nous sommes d'accord.
Mais si cela génère une dizaine de warning à chaque compilation,
et si le programmeur me ressemble, au bout d'un moment, il
s'habitue à ces dix warning, et le jour où un onzième apparaît,
il ne le voit pas, alors que celui là était peut-être utile.
Mutiler le code (avec
ou sans commentaire) ne fait qu'empirer une situation deja pas rose,
si tu veux mon avis.
Ben, je ne vois pas en quoi c'est une mutilation.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer writes: | >| > Je laisse le compilateur raler -- c'est une limitation stupide du langage. | >| > | >| > Certains utilisent l'ignoble __attributte__((unused)) de GCC, mais | >| > je ne l'ecris pas dans mes propres codes. | >| | >| Sauf que cet __attributte__ est spécifique à GCC non ? | >| Alors que le (void) est plus populaire, pour un résultat | >| semblable, non ? | > | > Je n'ecris pas et je n'enseigne pas mes eleves a ecrire du code | > populaire. J'essaie d'ecrire du code simple, correcte, lisible et | > maintenable. (Je n'y arrive pas toujours, mais j'essaie). | | Pour ma part, beaucoup plus simplement, quand il y a un paramètre | inutile dans une signature, je change la signature.
Cela n'est pas toujours possible -- ou alors, possible mais avec encore plus de monstruosites. Par exemple, considere le cas des frameworks ou des callbacks. Le type des functions est fige par le concepteur du framework, et les arguments passes aux callbacks ne sont pas forcement utilises.
Oui.
| Mais il semble que dans l'industrie, une fois qu'on a fixé une | interface, on répugne à la faire bouger.
Cela n'est pas seulement de la repugnance -- et on n'a pas forcement besoin d'aller dans l'industrie pour trouver cela, bien que l'industrie est plus grande productrice et consomatrice de frameworks.
ok
| Donc, on a ces 'unused parameters'. Qu'en fait-on ?
Comme je l'ai observe plus tot, soit on change de langage,
Sur un autre forum alors.
soit on laisse le warning car c'est un cas legitime ou le warning n'est le que le reflet d'une limitation stupide du langage.
Ca, que le langage soit imparfait, nous sommes d'accord. Mais si cela génère une dizaine de warning à chaque compilation, et si le programmeur me ressemble, au bout d'un moment, il s'habitue à ces dix warning, et le jour où un onzième apparaît, il ne le voit pas, alors que celui là était peut-être utile.
Mutiler le code (avec ou sans commentaire) ne fait qu'empirer une situation deja pas rose, si tu veux mon avis.
Ben, je ne vois pas en quoi c'est une mutilation.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Antoine Leca
En news:, Marc Boyer va escriure:
STRCAT(3) Linux Programmer's Manual STRCAT(3) SYNOPSIS #include <string.h>
* src does not need to be null terminated if it contains n or more characters. <couic2>
If src contains n or more characters, strcat() writes n+1
n est réutilisé, et a changé de sens au passage.
Avec strcat(), n est le nombre de caractères dans src (= strlen(src) ). Src ne peut _pas_ avoir /plus/ de n caractères. n+1 caractères seront écrits.
Avec strncat(), n est le troisième paramètre. Entre 1 et n+1 caractères seront écrits (chose qui n'est pas décrite, mais ce n'est pas trop grave.)
Si on utilise 'p' : : If src contains p or more characters, strcat() writes p+1 : characters to dest (p from src plus the terminating null : character). Therefore, the size of dest must be at least : strlen(dest)+p+1.
on voit assez vite que le "or more" est inopérant, ce qui laisse ¦ If src contains p characters, strcat() writes p+1 ¦ characters to dest (p from src plus the terminating null ¦ character). Therefore, the size of dest must be at least ¦ strlen(dest)+p+1.
et là on se demande pourquoi arrive pas à | strlen(dest)+strlen(src)+1.
?
A simple implementation of strncat() might be:
"simple-minded"
CONFORMING TO SVr4, 4.3BSD, C89, C99.
Et aussi SV avant r4, SIII et probablement (pas été cherché) des BSD plus anciens aussi. Je crois que strcat() est dans K&R1 et/ou V7.
Antoine
En news:slrnf7fequ.3mv.Marc.Boyer@localhost.localdomain,
Marc Boyer va escriure:
STRCAT(3) Linux Programmer's Manual STRCAT(3)
SYNOPSIS
#include <string.h>
* src does not need to be null terminated if it contains n
or more characters.
<couic2>
If src contains n or more characters, strcat() writes n+1
n est réutilisé, et a changé de sens au passage.
Avec strcat(), n est le nombre de caractères dans src (= strlen(src) ). Src
ne peut _pas_ avoir /plus/ de n caractères. n+1 caractères seront écrits.
Avec strncat(), n est le troisième paramètre. Entre 1 et n+1 caractères
seront écrits (chose qui n'est pas décrite, mais ce n'est pas trop grave.)
Si on utilise 'p' :
: If src contains p or more characters, strcat() writes p+1
: characters to dest (p from src plus the terminating null
: character). Therefore, the size of dest must be at least
: strlen(dest)+p+1.
on voit assez vite que le "or more" est inopérant, ce qui laisse
¦ If src contains p characters, strcat() writes p+1
¦ characters to dest (p from src plus the terminating null
¦ character). Therefore, the size of dest must be at least
¦ strlen(dest)+p+1.
et là on se demande pourquoi arrive pas à
| strlen(dest)+strlen(src)+1.
?
A simple implementation of strncat() might be:
"simple-minded"
CONFORMING TO
SVr4, 4.3BSD, C89, C99.
Et aussi SV avant r4, SIII et probablement (pas été cherché) des BSD plus
anciens aussi. Je crois que strcat() est dans K&R1 et/ou V7.
* src does not need to be null terminated if it contains n or more characters. <couic2>
If src contains n or more characters, strcat() writes n+1
n est réutilisé, et a changé de sens au passage.
Avec strcat(), n est le nombre de caractères dans src (= strlen(src) ). Src ne peut _pas_ avoir /plus/ de n caractères. n+1 caractères seront écrits.
Avec strncat(), n est le troisième paramètre. Entre 1 et n+1 caractères seront écrits (chose qui n'est pas décrite, mais ce n'est pas trop grave.)
Si on utilise 'p' : : If src contains p or more characters, strcat() writes p+1 : characters to dest (p from src plus the terminating null : character). Therefore, the size of dest must be at least : strlen(dest)+p+1.
on voit assez vite que le "or more" est inopérant, ce qui laisse ¦ If src contains p characters, strcat() writes p+1 ¦ characters to dest (p from src plus the terminating null ¦ character). Therefore, the size of dest must be at least ¦ strlen(dest)+p+1.
et là on se demande pourquoi arrive pas à | strlen(dest)+strlen(src)+1.
?
A simple implementation of strncat() might be:
"simple-minded"
CONFORMING TO SVr4, 4.3BSD, C89, C99.
Et aussi SV avant r4, SIII et probablement (pas été cherché) des BSD plus anciens aussi. Je crois que strcat() est dans K&R1 et/ou V7.
* src does not need to be null terminated if it contains n or more characters. <couic2>
If src contains n or more characters, strcat() writes n+1
n est réutilisé, et a changé de sens au passage.
Bien vu. J'essaye de me garder le pb sous le coude, et de faire remonter.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Vincent Lefevre
Dans l'article <46792e76$0$27404$, Harpo écrit:
Oui, un code doit compiler sans warning, déjà ça fout la trouille à celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait encore comme connerie moi ?).
Enfin, il y a des warnings qui peuvent uniquement être dûs à des limitations du compilateur (genre le compilateur qui indique que telle variable n'a peut-être pas été initialisée). Et forcer une initialisation à une valeur *arbitraire* peut rendre le code moins compréhensible et moins maintenable, et empêcher des détections de bugs avec des outils plus puissants.
Dans l'article <46792e76$0$27404$ba4acef3@news.orange.fr>,
Harpo <invalid@invalid.invalid> écrit:
Oui, un code doit compiler sans warning, déjà ça fout la trouille à
celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait
encore comme connerie moi ?).
Enfin, il y a des warnings qui peuvent uniquement être dûs à des
limitations du compilateur (genre le compilateur qui indique que
telle variable n'a peut-être pas été initialisée). Et forcer une
initialisation à une valeur *arbitraire* peut rendre le code moins
compréhensible et moins maintenable, et empêcher des détections de
bugs avec des outils plus puissants.
Oui, un code doit compiler sans warning, déjà ça fout la trouille à celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait encore comme connerie moi ?).
Enfin, il y a des warnings qui peuvent uniquement être dûs à des limitations du compilateur (genre le compilateur qui indique que telle variable n'a peut-être pas été initialisée). Et forcer une initialisation à une valeur *arbitraire* peut rendre le code moins compréhensible et moins maintenable, et empêcher des détections de bugs avec des outils plus puissants.
| > -Wcast-align -Wwrite-strings -Wsign-compare | > -Wunused | > -Wno-unused-parameter | | Tient, pourquoi donc ? | Moi, je suis plutôt pour la démarche. | void foo(int x, int y){ | (void) y; // unused parameter, parce que blabla...
Mon dieu !
Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une fonction pour laquelle je sais que je vais avoir besoin un jour ou l'autre de paramètres supplémentaires.
(void) y; /* unused parameter, parce que blabla... */
J'aime donc bien l'astuce, mais est-elle orthodoxe ?
-- Un économiste, c'est un expert qui saura demain pourquoi ce qu'il a prédit hier ne s'est pas produit aujourdhui.
--{ Gabriel Dos Reis a plopé ceci: }--
| > -Wcast-align -Wwrite-strings -Wsign-compare
| > -Wunused
| > -Wno-unused-parameter
|
| Tient, pourquoi donc ?
| Moi, je suis plutôt pour la démarche.
| void foo(int x, int y){
| (void) y; // unused parameter, parce que blabla...
Mon dieu !
Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une
fonction pour laquelle je sais que je vais avoir besoin un
jour ou l'autre de paramètres supplémentaires.
(void) y; /* unused parameter, parce que blabla... */
J'aime donc bien l'astuce, mais est-elle orthodoxe ?
--
Un économiste, c'est un expert qui saura demain pourquoi ce qu'il
a prédit hier ne s'est pas produit aujourdhui.
| > -Wcast-align -Wwrite-strings -Wsign-compare | > -Wunused | > -Wno-unused-parameter | | Tient, pourquoi donc ? | Moi, je suis plutôt pour la démarche. | void foo(int x, int y){ | (void) y; // unused parameter, parce que blabla...
Mon dieu !
Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une fonction pour laquelle je sais que je vais avoir besoin un jour ou l'autre de paramètres supplémentaires.
(void) y; /* unused parameter, parce que blabla... */
J'aime donc bien l'astuce, mais est-elle orthodoxe ?
-- Un économiste, c'est un expert qui saura demain pourquoi ce qu'il a prédit hier ne s'est pas produit aujourdhui.
Thierry B.
--{ Marc Boyer a plopé ceci: }--
Pour ma part, beaucoup plus simplement, quand il y a un paramètre inutile dans une signature, je change la signature.
C'est parfois un peu contraignant. Parfois, ça peut obliger
à recompiler un gazillion de petits programmes qui trainent partout sur tes machines. Alors qu'en "voidant" un paramètre, tu ne casses rien quand le .so change.
Peut-être je me trompe... Merci de me corriger, parce qu'en lisant ce fil, j'ai l'impression que j'ai encore beaucoup à apprendre.
Quel désavantage ? Il surprend le débutant.
Bah, tout le monde le sait, les débutants lisent la doc.
-- New from Bastard Industries: icmpcached - for when you don't want to wait up to 100ms for your echo replies. icmpcached will ping all the hosts on the Internet and keep the results in a handy hash table so you can ping quickly and efficently. Now with icmpswapd integration!
--{ Marc Boyer a plopé ceci: }--
Pour ma part, beaucoup plus simplement, quand il y a un paramètre
inutile dans une signature, je change la signature.
C'est parfois un peu contraignant. Parfois, ça peut obliger
à recompiler un gazillion de petits programmes qui trainent
partout sur tes machines. Alors qu'en "voidant" un paramètre,
tu ne casses rien quand le .so change.
Peut-être je me trompe... Merci de me corriger, parce qu'en
lisant ce fil, j'ai l'impression que j'ai encore beaucoup
à apprendre.
Quel désavantage ? Il surprend le débutant.
Bah, tout le monde le sait, les débutants lisent la doc.
--
New from Bastard Industries: icmpcached - for when you don't want to
wait up to 100ms for your echo replies. icmpcached will ping all the
hosts on the Internet and keep the results in a handy hash table so
you can ping quickly and efficently. Now with icmpswapd integration!
Pour ma part, beaucoup plus simplement, quand il y a un paramètre inutile dans une signature, je change la signature.
C'est parfois un peu contraignant. Parfois, ça peut obliger
à recompiler un gazillion de petits programmes qui trainent partout sur tes machines. Alors qu'en "voidant" un paramètre, tu ne casses rien quand le .so change.
Peut-être je me trompe... Merci de me corriger, parce qu'en lisant ce fil, j'ai l'impression que j'ai encore beaucoup à apprendre.
Quel désavantage ? Il surprend le débutant.
Bah, tout le monde le sait, les débutants lisent la doc.
-- New from Bastard Industries: icmpcached - for when you don't want to wait up to 100ms for your echo replies. icmpcached will ping all the hosts on the Internet and keep the results in a handy hash table so you can ping quickly and efficently. Now with icmpswapd integration!
Gabriel Dos Reis
Harpo writes:
| On Wed, 20 Jun 2007 14:06:06 +0000, Vincent Lefevre wrote: | | >> Oui, un code doit compiler sans warning, déjà ça fout la trouille à | >> celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait | >> encore comme connerie moi ?). | > | > Enfin, il y a des warnings qui peuvent uniquement être dûs à des | > limitations du compilateur (genre le compilateur qui indique que | > telle variable n'a peut-être pas été initialisée). Et forcer une | > initialisation à une valeur *arbitraire* peut rendre le code moins | > compréhensible et moins maintenable, et empêcher des détections de | > bugs avec des outils plus puissants. | | Je pense que c'est moins grave que d'inhiber la génération de warning | par une option de compile ou de donner l'habitude de voir des warning et | de trouver ça normal.
Je ne pense pas "donner l'habitude de voir des warnings et de trouver ca normal".
-- Gaby
Harpo <invalid@invalid.invalid> writes:
| On Wed, 20 Jun 2007 14:06:06 +0000, Vincent Lefevre wrote:
|
| >> Oui, un code doit compiler sans warning, déjà ça fout la trouille à
| >> celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait
| >> encore comme connerie moi ?).
| >
| > Enfin, il y a des warnings qui peuvent uniquement être dûs à des
| > limitations du compilateur (genre le compilateur qui indique que
| > telle variable n'a peut-être pas été initialisée). Et forcer une
| > initialisation à une valeur *arbitraire* peut rendre le code moins
| > compréhensible et moins maintenable, et empêcher des détections de
| > bugs avec des outils plus puissants.
|
| Je pense que c'est moins grave que d'inhiber la génération de warning
| par une option de compile ou de donner l'habitude de voir des warning et
| de trouver ça normal.
Je ne pense pas "donner l'habitude de voir des warnings et de trouver
ca normal".
| On Wed, 20 Jun 2007 14:06:06 +0000, Vincent Lefevre wrote: | | >> Oui, un code doit compiler sans warning, déjà ça fout la trouille à | >> celui qui ne l'a pas écrit et qui le compile (qu'est-ce que j'ai fait | >> encore comme connerie moi ?). | > | > Enfin, il y a des warnings qui peuvent uniquement être dûs à des | > limitations du compilateur (genre le compilateur qui indique que | > telle variable n'a peut-être pas été initialisée). Et forcer une | > initialisation à une valeur *arbitraire* peut rendre le code moins | > compréhensible et moins maintenable, et empêcher des détections de | > bugs avec des outils plus puissants. | | Je pense que c'est moins grave que d'inhiber la génération de warning | par une option de compile ou de donner l'habitude de voir des warning et | de trouver ça normal.
Je ne pense pas "donner l'habitude de voir des warnings et de trouver ca normal".
-- Gaby
Gabriel Dos Reis
"Thierry B." writes:
| --{ Gabriel Dos Reis a plopé ceci: }-- | | >| > -Wcast-align -Wwrite-strings -Wsign-compare | >| > -Wunused | >| > -Wno-unused-parameter | >| | >| Tient, pourquoi donc ? | >| Moi, je suis plutôt pour la démarche. | >| void foo(int x, int y){ | >| (void) y; // unused parameter, parce que blabla... | > | > Mon dieu ! | | Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une | fonction pour laquelle je sais que je vais avoir besoin un | jour ou l'autre de paramètres supplémentaires. | | (void) y; /* unused parameter, parce que blabla... */ | | J'aime donc bien l'astuce, mais est-elle orthodoxe ?
Je ne sais pas si elle est orthodoxe : elle ne passe pas le "code review" chez moi, et un etudiant qui me rend un projet avec ce machin la dedans aura probablement une note proche de F.
Maintenant, si je travaille dans un projet ou le manager a decide cela, je l'ecrirai mais je lui dirai ce que j'en pense.
-- Gaby
"Thierry B." <tth@prout.stex> writes:
| --{ Gabriel Dos Reis a plopé ceci: }--
|
| >| > -Wcast-align -Wwrite-strings -Wsign-compare
| >| > -Wunused
| >| > -Wno-unused-parameter
| >|
| >| Tient, pourquoi donc ?
| >| Moi, je suis plutôt pour la démarche.
| >| void foo(int x, int y){
| >| (void) y; // unused parameter, parce que blabla...
| >
| > Mon dieu !
|
| Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une
| fonction pour laquelle je sais que je vais avoir besoin un
| jour ou l'autre de paramètres supplémentaires.
|
| (void) y; /* unused parameter, parce que blabla... */
|
| J'aime donc bien l'astuce, mais est-elle orthodoxe ?
Je ne sais pas si elle est orthodoxe : elle ne passe pas le
"code review" chez moi, et un etudiant qui me rend un projet avec ce
machin la dedans aura probablement une note proche de F.
Maintenant, si je travaille dans un projet ou le manager a decide
cela, je l'ecrirai mais je lui dirai ce que j'en pense.
| --{ Gabriel Dos Reis a plopé ceci: }-- | | >| > -Wcast-align -Wwrite-strings -Wsign-compare | >| > -Wunused | >| > -Wno-unused-parameter | >| | >| Tient, pourquoi donc ? | >| Moi, je suis plutôt pour la démarche. | >| void foo(int x, int y){ | >| (void) y; // unused parameter, parce que blabla... | > | > Mon dieu ! | | Je trouve ça plutôt bien. Parfois, il m'arrive d'écrire une | fonction pour laquelle je sais que je vais avoir besoin un | jour ou l'autre de paramètres supplémentaires. | | (void) y; /* unused parameter, parce que blabla... */ | | J'aime donc bien l'astuce, mais est-elle orthodoxe ?
Je ne sais pas si elle est orthodoxe : elle ne passe pas le "code review" chez moi, et un etudiant qui me rend un projet avec ce machin la dedans aura probablement une note proche de F.
Maintenant, si je travaille dans un projet ou le manager a decide cela, je l'ecrirai mais je lui dirai ce que j'en pense.
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
| In article , | Gabriel Dos Reis wrote: | >Je ne pense pas "donner l'habitude de voir des warnings et de trouver | >ca normal". | | De toutes facons, gcc est assez minable sur pas mal de warnings et de | non warnings. | | Je dis pas que c'est facile, comme boulot, mais les warnings du style | `la comparaison en question est toujours valide vu le type de donnees | considere', c'est beaucoup plus du bruit qu'autre chose sur du code | vaguement portable... et ca a tendance a cacher d'autres vrais problemes.
Cela ne depend pas que de moi -- la nouvelle generation est beaucoup plus enthousiaste que moi en ce qui concerne les warnings.
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <m3sl8l9h8r.fsf@zeus.integrable-solutions.net>,
| Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| >Je ne pense pas "donner l'habitude de voir des warnings et de trouver
| >ca normal".
|
| De toutes facons, gcc est assez minable sur pas mal de warnings et de
| non warnings.
|
| Je dis pas que c'est facile, comme boulot, mais les warnings du style
| `la comparaison en question est toujours valide vu le type de donnees
| considere', c'est beaucoup plus du bruit qu'autre chose sur du code
| vaguement portable... et ca a tendance a cacher d'autres vrais problemes.
Cela ne depend pas que de moi -- la nouvelle generation est beaucoup
plus enthousiaste que moi en ce qui concerne les warnings.
| In article , | Gabriel Dos Reis wrote: | >Je ne pense pas "donner l'habitude de voir des warnings et de trouver | >ca normal". | | De toutes facons, gcc est assez minable sur pas mal de warnings et de | non warnings. | | Je dis pas que c'est facile, comme boulot, mais les warnings du style | `la comparaison en question est toujours valide vu le type de donnees | considere', c'est beaucoup plus du bruit qu'autre chose sur du code | vaguement portable... et ca a tendance a cacher d'autres vrais problemes.
Cela ne depend pas que de moi -- la nouvelle generation est beaucoup plus enthousiaste que moi en ce qui concerne les warnings.
