mais ici la norme aurait du le définir
mais ici la norme aurait du le définir
mais ici la norme aurait du le définir
James Kanze wrote:Ce n'est même pas un anglicisme. Disambiguate ne résonne pas 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
Allemagne. 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".
James Kanze wrote:
Ce n'est même pas un anglicisme. Disambiguate ne résonne pas 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
Allemagne. 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".
James Kanze wrote:Ce n'est même pas un anglicisme. Disambiguate ne résonne pas 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
Allemagne. 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".
On Tue, 12 Oct 2004 17:31:14 +0200, "Alexandre"
:mais ici la norme aurait du le définir
Non. C'est l'inconvénient de la compatibilité avec le C : le C++ se
traîne plein de casserolles de ce type.
On Tue, 12 Oct 2004 17:31:14 +0200, "Alexandre"
<alex.g@netcourrier.com>:
mais ici la norme aurait du le définir
Non. C'est l'inconvénient de la compatibilité avec le C : le C++ se
traîne plein de casserolles de ce type.
On Tue, 12 Oct 2004 17:31:14 +0200, "Alexandre"
:mais ici la norme aurait du le définir
Non. C'est l'inconvénient de la compatibilité avec le C : le C++ se
traîne plein de casserolles de ce type.
"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.
"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.
"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.
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.
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.
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.
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.
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.
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.
Surtout, il exige qu'on déclare la variable dans une ligne à part,
avant d'appeler la fonction. Il y a des cas où on aimerait s'en
passer.
Surtout, il exige qu'on déclare la variable dans une ligne à part,
avant d'appeler la fonction. Il y a des cas où on aimerait s'en
passer.
Surtout, il exige qu'on déclare la variable dans une ligne à part,
avant d'appeler la fonction. Il y a des cas où on aimerait s'en
passer.
S'ils doivent être longs pour être corrects, il faut
les écrire ainsi.
S'ils doivent être longs pour être corrects, il faut
les écrire ainsi.
S'ils doivent être longs pour être corrects, il faut
les écrire ainsi.
