Voila, j'ai fait une map :
map <CoupleInt, double>myMap;
destinée a accueillir une valeur relative a un couple d'entiers
CoupleInt dont la syntaxe de classe est la suivante :
class CoupleInt
{
public:
CoupleInt();
CoupleInt(int, int);
CoupleInt(const CoupleInt&);
~CoupleInt();
private:
int first;
int second;
};
Lorsque je fais l'appel (par exemple)
double myDoubleValue = 3.02;
CoupleInt couple = CoupleInt(3,2);
myMap[couple] = myDoubleValue;
Ben... franchement, je n'ai encore jamais eu l'occasion d'utiliser std::pair<>. Je me demande même si cette classe n'a pas été créée uniquement comme helper pour std::map<>.
Il y au moins aussi son emploi pour std::equal_range qui est important. Mais je pense que c'est vraiment une mauvaise idée pour la norme d'avoir inventé un type anonyme pour deux valeurs quelconques alors qu'on aurait pu faire simplement un ou deux types avec des noms plus précis... Je déteste quand un document important donne une justification à du mauvais code !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message jb3gm0dh0e74eccic33hksddv5m6tsk496@4ax.com,
Ben... franchement, je n'ai encore jamais eu l'occasion d'utiliser
std::pair<>. Je me demande même si cette classe n'a pas été créée
uniquement comme helper pour std::map<>.
Il y au moins aussi son emploi pour std::equal_range qui est important.
Mais je pense que c'est vraiment une mauvaise idée pour la norme
d'avoir inventé un type anonyme pour deux valeurs quelconques alors
qu'on aurait pu faire simplement un ou deux types avec des noms plus
précis... Je déteste quand un document important donne une
justification à du mauvais code !
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Ben... franchement, je n'ai encore jamais eu l'occasion d'utiliser std::pair<>. Je me demande même si cette classe n'a pas été créée uniquement comme helper pour std::map<>.
Il y au moins aussi son emploi pour std::equal_range qui est important. Mais je pense que c'est vraiment une mauvaise idée pour la norme d'avoir inventé un type anonyme pour deux valeurs quelconques alors qu'on aurait pu faire simplement un ou deux types avec des noms plus précis... Je déteste quand un document important donne une justification à du mauvais code !
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans le message ,
Une première solution est évidemment de passer par référence les variables qui doivent recevoir les valeurs à retourner. J'utilise souvent cette possibilité, mais pas toujours, car parfois le code ne serait pas clair. Par exemple, il peut être difficile de trouver un nom de fonction qui indique sans ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer deux données à moins que ce soit un « couple » très logique ayant un nom précis et une utilisation ailleurs.
Mes élèves ont souvent de la difficulté à bien nommer les fonctions et les variables ou à trouver des commentaires pertinents. Lorsque ça leur arrive, je leur dis de ne pas baisser les bras, de chercher encore... ou de venir me voir. Mon expérience me dit que si on ne peut trouver un nom clair, c'est que le code n'est pas bien structuré au départ... En particulier, je ne vois pas de problème avec les paramètres de sortie : ils sont rares parce qu'ils sont rarement nécessaires. S'ils sont nécessaires, ça devrait paraître facilement dans le nom de la fonction (et/ou, en plus, du paramètre qu'on passe).
Une autre possibilité est de retourner une instance de classe qui englobe toutes les données à retourner. Mais parfois, lorsque le besoin est très local, il n'est pas justifié de passer du temps à créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message 8s2lm0t9bdb8qbglcgscqe3p8ughae057j@4ax.com,
Une première solution est évidemment de passer par référence les
variables qui doivent recevoir les valeurs à retourner.
J'utilise souvent cette possibilité, mais pas toujours, car
parfois le code ne serait pas clair. Par exemple, il peut être
difficile de trouver un nom de fonction qui indique sans
ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer
deux données à moins que ce soit un « couple » très logique ayant
un nom précis et une utilisation ailleurs.
Mes élèves ont souvent de la difficulté à bien nommer les fonctions
et les variables ou à trouver des commentaires pertinents. Lorsque
ça leur arrive, je leur dis de ne pas baisser les bras, de chercher
encore... ou de venir me voir. Mon expérience me dit que si on ne
peut trouver un nom clair, c'est que le code n'est pas bien structuré
au départ... En particulier, je ne vois pas de problème avec les
paramètres de sortie : ils sont rares parce qu'ils sont rarement
nécessaires. S'ils sont nécessaires, ça devrait paraître facilement
dans le nom de la fonction (et/ou, en plus, du paramètre qu'on passe).
Une autre possibilité est de retourner une instance de classe qui
englobe toutes les données à retourner. Mais parfois, lorsque le
besoin est très local, il n'est pas justifié de passer du temps à
créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Une première solution est évidemment de passer par référence les variables qui doivent recevoir les valeurs à retourner. J'utilise souvent cette possibilité, mais pas toujours, car parfois le code ne serait pas clair. Par exemple, il peut être difficile de trouver un nom de fonction qui indique sans ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer deux données à moins que ce soit un « couple » très logique ayant un nom précis et une utilisation ailleurs.
Mes élèves ont souvent de la difficulté à bien nommer les fonctions et les variables ou à trouver des commentaires pertinents. Lorsque ça leur arrive, je leur dis de ne pas baisser les bras, de chercher encore... ou de venir me voir. Mon expérience me dit que si on ne peut trouver un nom clair, c'est que le code n'est pas bien structuré au départ... En particulier, je ne vois pas de problème avec les paramètres de sortie : ils sont rares parce qu'ils sont rarement nécessaires. S'ils sont nécessaires, ça devrait paraître facilement dans le nom de la fonction (et/ou, en plus, du paramètre qu'on passe).
Une autre possibilité est de retourner une instance de classe qui englobe toutes les données à retourner. Mais parfois, lorsque le besoin est très local, il n'est pas justifié de passer du temps à créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Michel Michaud
Dans le message ,
Dans mon code, une fonction qui prend un argument par référence non constante indique sans ambiguïté que l'argument sera modifié. Mais c'est vrai que ce n'est pas visible dans le code qui appelle la fonction.
Ça devrait pourtant. Il faut bien nommer les fonctions... Mais peut-être as-tu un peu de difficultés à faire ça tout en donnant des noms anglais :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message dshlm0545tnjsbp06bjucki1tmnrprn4of@4ax.com,
Dans mon code, une fonction qui prend un argument par référence non
constante indique sans ambiguïté que l'argument sera modifié. Mais
c'est vrai que ce n'est pas visible dans le code qui appelle la
fonction.
Ça devrait pourtant. Il faut bien nommer les fonctions... Mais
peut-être as-tu un peu de difficultés à faire ça tout en donnant
des noms anglais :-)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans mon code, une fonction qui prend un argument par référence non constante indique sans ambiguïté que l'argument sera modifié. Mais c'est vrai que ce n'est pas visible dans le code qui appelle la fonction.
Ça devrait pourtant. Il faut bien nommer les fonctions... Mais peut-être as-tu un peu de difficultés à faire ça tout en donnant des noms anglais :-)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Fabien LE LEZ
On Mon, 11 Oct 2004 16:51:55 -0400, "Michel Michaud" :
la norme [...] Je déteste quand un document important donne une justification à du mauvais code !
T'inquiète pas, si jamais tes élèves sont capables de lire la norme, ils n'ont plus besoin de toi ;-)
-- ;-)
On Mon, 11 Oct 2004 16:51:55 -0400, "Michel Michaud" <mm@gdzid.com>:
la norme [...]
Je déteste quand un document important donne une
justification à du mauvais code !
T'inquiète pas, si jamais tes élèves sont capables de lire la norme,
ils n'ont plus besoin de toi ;-)
On Mon, 11 Oct 2004 16:58:20 -0400, "Michel Michaud" :
Mais c'est vrai que ce n'est pas visible dans le code qui appelle la fonction.
Ça devrait pourtant.
Il faut bien nommer les fonctions...
Le nom de la fonction n'a rien à voir dans le fait qu'un appel par référence non constante n'est pas visible lors de l'appel.
-- ;-)
Michel Michaud
Dans le message ,
On Mon, 11 Oct 2004 16:58:20 -0400, "Michel Michaud" :
Mais c'est vrai que ce n'est pas visible dans le code qui appelle la fonction.
Ça devrait pourtant.
Il faut bien nommer les fonctions...
Le nom de la fonction n'a rien à voir dans le fait qu'un appel par référence non constante n'est pas visible lors de l'appel.
Ça dépend de l'interprétation du mot visible effectivement. Mais mon Larousse donne, comme deuxième définition : « Facilement perceptible : évident, manifeste ». C'est de celle-là qui m'intéressait, car c'est elle qui est importante pour la lisibilité du code (la visibilité m'intéresse peu en informatique :-).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message pculm0d3hjt3uhbvi2uj261edhsd6j0mt7@4ax.com,
On Mon, 11 Oct 2004 16:58:20 -0400, "Michel Michaud" <mm@gdzid.com>:
Mais c'est vrai que ce n'est pas visible dans le code qui appelle
la fonction.
Ça devrait pourtant.
Il faut bien nommer les fonctions...
Le nom de la fonction n'a rien à voir dans le fait qu'un appel par
référence non constante n'est pas visible lors de l'appel.
Ça dépend de l'interprétation du mot visible effectivement. Mais
mon Larousse donne, comme deuxième définition : « Facilement
perceptible : évident, manifeste ». C'est de celle-là qui
m'intéressait, car c'est elle qui est importante pour la lisibilité
du code (la visibilité m'intéresse peu en informatique :-).
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
On Mon, 11 Oct 2004 16:58:20 -0400, "Michel Michaud" :
Mais c'est vrai que ce n'est pas visible dans le code qui appelle la fonction.
Ça devrait pourtant.
Il faut bien nommer les fonctions...
Le nom de la fonction n'a rien à voir dans le fait qu'un appel par référence non constante n'est pas visible lors de l'appel.
Ça dépend de l'interprétation du mot visible effectivement. Mais mon Larousse donne, comme deuxième définition : « Facilement perceptible : évident, manifeste ». C'est de celle-là qui m'intéressait, car c'est elle qui est importante pour la lisibilité du code (la visibilité m'intéresse peu en informatique :-).
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
"Vincent Lascaux" writes:
| > Le problème, c'est que la suite de tokens « int ( i ) » peut être | > interprété soit comme une valeur, soit come une déclaration d'une | > variable i (variable qui pourrait, lui, être le paramètre d'une | > fonction). Et la norme dit que chaque fois qu'il y a ambigüité, et que | > les deux sont légaux, c'est la declaration qui prime. | | Est ce que tu sais ce qui a poussé le choix dans ce sens ?
Héritage C.
Mais comme Stroustrup l'explique dans D&E, même le compilateur du temps de K&R1 ne les acceptais pas -- même si K&R1 disait que c'était valide.
-- Gaby
"Vincent Lascaux" <nospam@nospam.org> writes:
| > Le problème, c'est que la suite de tokens « int ( i ) » peut être
| > interprété soit comme une valeur, soit come une déclaration d'une
| > variable i (variable qui pourrait, lui, être le paramètre d'une
| > fonction). Et la norme dit que chaque fois qu'il y a ambigüité, et que
| > les deux sont légaux, c'est la declaration qui prime.
|
| Est ce que tu sais ce qui a poussé le choix dans ce sens ?
Héritage C.
Mais comme Stroustrup l'explique dans D&E, même le compilateur du
temps de K&R1 ne les acceptais pas -- même si K&R1 disait que c'était
valide.
| > Le problème, c'est que la suite de tokens « int ( i ) » peut être | > interprété soit comme une valeur, soit come une déclaration d'une | > variable i (variable qui pourrait, lui, être le paramètre d'une | > fonction). Et la norme dit que chaque fois qu'il y a ambigüité, et que | > les deux sont légaux, c'est la declaration qui prime. | | Est ce que tu sais ce qui a poussé le choix dans ce sens ?
Héritage C.
Mais comme Stroustrup l'explique dans D&E, même le compilateur du temps de K&R1 ne les acceptais pas -- même si K&R1 disait que c'était valide.
-- Gaby
Andre Heinen
On Mon, 11 Oct 2004 16:57:09 -0400, "Michel Michaud" wrote:
Dans le message ,
Par exemple, il peut être difficile de trouver un nom de fonction qui indique sans ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer deux données à moins que ce soit un « couple » très logique ayant un nom précis et une utilisation ailleurs.
J'ai l'impression qu'on est en train de "glisser" vers une bagarre entre "pro-struct" et "anti-struct". Je rappelle donc que je n'ai jamais utilisé cette méthode que très rarement. En général, je fais comme tu dis.
Mais il y a eu des cas où j'ai eu l'impression que ce n'était pas idéal. Il m'est arrivé, en me "forçant", comme tu dis, de trouver des noms de fonction qui étaient explicites mais longs et lourds. Ils ne me satisfaisaient pas.
On a également parlé, ces derniers temps, de la difficulté de trouver des identificateurs explicites en français, en particulier si le compilateur utilisé impose de renoncer aux accents. Tu viens toi-même de donner, dans un autre fil, un exemple avec trouve/trouvé/trouver/decouvert. Je crois qu'il n'est pas toujours si facile de "se forcer".
Et puis franchement, je ne vois pas de problème avec le fait de retourner une std::pair. Si une fonction retourne deux valeurs, ça ne me paraît pas plus difficile à comprendre que si elle n'en retourne qu'une seule.
Mon expérience me dit que si on ne peut trouver un nom clair, c'est que le code n'est pas bien structuré au départ...
Tu me donnes envie d'aller relire mon code... ;-) Malheureusement, je n'ai plus utilisé de std::pair depuis longtemps, et je n'ai plus ce code à ma disposition. Nous ne pourrons donc jamais vérifier s'il était mal structuré.
Une autre possibilité est de retourner une instance de classe qui englobe toutes les données à retourner. Mais parfois, lorsque le besoin est très local, il n'est pas justifié de passer du temps à créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
Oui, mais dans ce cas-ci, le code soigné, c'est une struct à la C. Si on n'a pas de fonctions membres, le code est plus petit et plus clair. Encore une fois, je n'utilise que rarement cette solution, et lorsque le besoin est "très local". En fait, je pense spécifiquement à une struct encapsulée dans une classe.
-- Andre Heinen My address, rot13-encoded: n qbg urvara ng rhebcrnayvax qbg pbz
On Mon, 11 Oct 2004 16:57:09 -0400, "Michel Michaud"
<mm@gdzid.com> wrote:
Dans le message 8s2lm0t9bdb8qbglcgscqe3p8ughae057j@4ax.com,
Par exemple, il peut être
difficile de trouver un nom de fonction qui indique sans
ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer
deux données à moins que ce soit un « couple » très logique ayant
un nom précis et une utilisation ailleurs.
J'ai l'impression qu'on est en train de "glisser" vers une
bagarre entre "pro-struct" et "anti-struct". Je rappelle donc
que je n'ai jamais utilisé cette méthode que très rarement. En
général, je fais comme tu dis.
Mais il y a eu des cas où j'ai eu l'impression que ce n'était pas
idéal. Il m'est arrivé, en me "forçant", comme tu dis, de
trouver des noms de fonction qui étaient explicites mais longs et
lourds. Ils ne me satisfaisaient pas.
On a également parlé, ces derniers temps, de la difficulté de
trouver des identificateurs explicites en français, en
particulier si le compilateur utilisé impose de renoncer aux
accents. Tu viens toi-même de donner, dans un autre fil, un
exemple avec trouve/trouvé/trouver/decouvert. Je crois qu'il
n'est pas toujours si facile de "se forcer".
Et puis franchement, je ne vois pas de problème avec le fait de
retourner une std::pair. Si une fonction retourne deux valeurs,
ça ne me paraît pas plus difficile à comprendre que si elle n'en
retourne qu'une seule.
Mon expérience me dit que si on ne
peut trouver un nom clair, c'est que le code n'est pas bien structuré
au départ...
Tu me donnes envie d'aller relire mon code... ;-)
Malheureusement, je n'ai plus utilisé de std::pair depuis
longtemps, et je n'ai plus ce code à ma disposition. Nous ne
pourrons donc jamais vérifier s'il était mal structuré.
Une autre possibilité est de retourner une instance de classe qui
englobe toutes les données à retourner. Mais parfois, lorsque le
besoin est très local, il n'est pas justifié de passer du temps à
créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
Oui, mais dans ce cas-ci, le code soigné, c'est une struct à la
C. Si on n'a pas de fonctions membres, le code est plus petit et
plus clair. Encore une fois, je n'utilise que rarement cette
solution, et lorsque le besoin est "très local". En fait, je
pense spécifiquement à une struct encapsulée dans une classe.
--
Andre Heinen
My address, rot13-encoded: n qbg urvara ng rhebcrnayvax qbg pbz
On Mon, 11 Oct 2004 16:57:09 -0400, "Michel Michaud" wrote:
Dans le message ,
Par exemple, il peut être difficile de trouver un nom de fonction qui indique sans ambiguïté que la fonction modifie les arguments.
Difficile ? C'est tout ? Alors on se force et on évite de renvoyer deux données à moins que ce soit un « couple » très logique ayant un nom précis et une utilisation ailleurs.
J'ai l'impression qu'on est en train de "glisser" vers une bagarre entre "pro-struct" et "anti-struct". Je rappelle donc que je n'ai jamais utilisé cette méthode que très rarement. En général, je fais comme tu dis.
Mais il y a eu des cas où j'ai eu l'impression que ce n'était pas idéal. Il m'est arrivé, en me "forçant", comme tu dis, de trouver des noms de fonction qui étaient explicites mais longs et lourds. Ils ne me satisfaisaient pas.
On a également parlé, ces derniers temps, de la difficulté de trouver des identificateurs explicites en français, en particulier si le compilateur utilisé impose de renoncer aux accents. Tu viens toi-même de donner, dans un autre fil, un exemple avec trouve/trouvé/trouver/decouvert. Je crois qu'il n'est pas toujours si facile de "se forcer".
Et puis franchement, je ne vois pas de problème avec le fait de retourner une std::pair. Si une fonction retourne deux valeurs, ça ne me paraît pas plus difficile à comprendre que si elle n'en retourne qu'une seule.
Mon expérience me dit que si on ne peut trouver un nom clair, c'est que le code n'est pas bien structuré au départ...
Tu me donnes envie d'aller relire mon code... ;-) Malheureusement, je n'ai plus utilisé de std::pair depuis longtemps, et je n'ai plus ce code à ma disposition. Nous ne pourrons donc jamais vérifier s'il était mal structuré.
Une autre possibilité est de retourner une instance de classe qui englobe toutes les données à retourner. Mais parfois, lorsque le besoin est très local, il n'est pas justifié de passer du temps à créer une classe avec une interface soignée.
Il est toujours justifié de faire du code soigné. Non ?
Oui, mais dans ce cas-ci, le code soigné, c'est une struct à la C. Si on n'a pas de fonctions membres, le code est plus petit et plus clair. Encore une fois, je n'utilise que rarement cette solution, et lorsque le besoin est "très local". En fait, je pense spécifiquement à une struct encapsulée dans une classe.
-- Andre Heinen My address, rot13-encoded: n qbg urvara ng rhebcrnayvax qbg pbz
Falk Tannhäuser
James Kanze wrote:
Ce n'est même pas un anglicisme. « Disambiguate » ne résonne pa s mieux en anglais. Mais j'aimerais bien avoir un mot pour la chose (encore qu'au fond, lever l'ambiguïté me semble faire l'affaire d'une faç on suffisante). Je ne pourrais même pas blâmer mes sejours en Allemagn e. Les allemands aiment bien créer de nouveaux mots, mais ça ne me viendrait pas à l'esprit non plus d'y écrire « entdoppeldeutigen ».
:-)
J'aurais dit "eine Doppeldeutigkeit (oder Mehrdeutigkeit) auflösen"
Falk
James Kanze wrote:
Ce n'est même pas un anglicisme. « Disambiguate » ne résonne pa s mieux
en anglais. Mais j'aimerais bien avoir un mot pour la chose (encore
qu'au fond, lever l'ambiguïté me semble faire l'affaire d'une faç on
suffisante). Je ne pourrais même pas blâmer mes sejours en Allemagn e.
Les allemands aiment bien créer de nouveaux mots, mais ça ne me
viendrait pas à l'esprit non plus d'y écrire « entdoppeldeutigen ».
:-)
J'aurais dit "eine Doppeldeutigkeit (oder Mehrdeutigkeit) auflösen"
Ce n'est même pas un anglicisme. « Disambiguate » ne résonne pa s mieux en anglais. Mais j'aimerais bien avoir un mot pour la chose (encore qu'au fond, lever l'ambiguïté me semble faire l'affaire d'une faç on suffisante). Je ne pourrais même pas blâmer mes sejours en Allemagn e. Les allemands aiment bien créer de nouveaux mots, mais ça ne me viendrait pas à l'esprit non plus d'y écrire « entdoppeldeutigen ».
:-)
J'aurais dit "eine Doppeldeutigkeit (oder Mehrdeutigkeit) auflösen"
Falk
Alexandre
"Fabien LE LEZ" a écrit dans le message de news:
On Mon, 11 Oct 2004 20:39:42 +0200, "Alexandre" :
AMA il devrait même balancer une erreur ;-)
Ben non : les messages d'erreurs sont définis par la norme, tandis que les warnings sont laissés au choix de l'éditeur.
mais ici la norme aurait du le définir, du moins c'est mon avis.
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le message de news:
bonlm05uv58u3defkla295atqdc41uurrn@4ax.com...
On Mon, 11 Oct 2004 20:39:42 +0200, "Alexandre"
<alex.g@netcourrier.com>:
AMA il devrait même balancer une erreur ;-)
Ben non : les messages d'erreurs sont définis par la norme, tandis que
les warnings sont laissés au choix de l'éditeur.
mais ici la norme aurait du le définir, du moins c'est mon avis.
