"" writes:Jean-Marc Bourguet wrote:
> (Marc Espie) writes:
>
>> In article <i5vilk$k86$,
>> wrote:
>> >Petit quizz : comment sont évaluées :
>> > a - b - c ?
>> > a / b / c ?
>> >
>> >P.S: à mon avis, un programmeur écrivant des expressions comme
>> >ci-dessus mérite un magistral coup de pied au cul !
>>
>> A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
>> qui se proclame "programmeur" merite un petit retour sur ses bancs
>> d'ecole, section arithmetique elementaire...
>
> Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
"caribou@server.invalid" <caribou@server.invalid> writes:
Jean-Marc Bourguet wrote:
> espie@lain.home (Marc Espie) writes:
>
>> In article <i5vilk$k86$1@adenine.netfront.net>,
>> caribou@server.invalid <caribou@server.invalid> wrote:
>> >Petit quizz : comment sont évaluées :
>> > a - b - c ?
>> > a / b / c ?
>> >
>> >P.S: à mon avis, un programmeur écrivant des expressions comme
>> >ci-dessus mérite un magistral coup de pied au cul !
>>
>> A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
>> qui se proclame "programmeur" merite un petit retour sur ses bancs
>> d'ecole, section arithmetique elementaire...
>
> Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
"" writes:Jean-Marc Bourguet wrote:
> (Marc Espie) writes:
>
>> In article <i5vilk$k86$,
>> wrote:
>> >Petit quizz : comment sont évaluées :
>> > a - b - c ?
>> > a / b / c ?
>> >
>> >P.S: à mon avis, un programmeur écrivant des expressions comme
>> >ci-dessus mérite un magistral coup de pied au cul !
>>
>> A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
>> qui se proclame "programmeur" merite un petit retour sur ses bancs
>> d'ecole, section arithmetique elementaire...
>
> Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
qui se proclame "programmeur" merite un petit retour sur ses bancs
d'ecole, section arithmetique elementaire...
Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
qui se proclame "programmeur" merite un petit retour sur ses bancs
d'ecole, section arithmetique elementaire...
Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
A mon avis, quelqu'un qui ne sait pas lire les expressions ci-dessus et
qui se proclame "programmeur" merite un petit retour sur ses bancs
d'ecole, section arithmetique elementaire...
Ou alors il a trop fait d'APL recemment. :-)
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
Le 06 Sep 2010 11:06:02 +0200, Jean-Marc Bourguet écrivait :a - b - c ?
a / b / c ?
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
Ouaips. Sauf que lorsque tu travailles dans plusieurs langages qui
sont orthogonaux, tu vas très vite dans le mur.
Par ailleurs, je connais des compilos (gcc pour ne pas le nommer)
qui d'une version à l'autre se comportent différemment.
En d'autres termes, je ne vois pas l'intérêt d'économiser une
parenthèse lorsque cela évite une étape de debug qui peut être assez
laborieuse.
Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Le 06 Sep 2010 11:06:02 +0200, Jean-Marc Bourguet écrivait :
a - b - c ?
a / b / c ?
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
Ouaips. Sauf que lorsque tu travailles dans plusieurs langages qui
sont orthogonaux, tu vas très vite dans le mur.
Par ailleurs, je connais des compilos (gcc pour ne pas le nommer)
qui d'une version à l'autre se comportent différemment.
En d'autres termes, je ne vois pas l'intérêt d'économiser une
parenthèse lorsque cela évite une étape de debug qui peut être assez
laborieuse.
Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Le 06 Sep 2010 11:06:02 +0200, Jean-Marc Bourguet écrivait :a - b - c ?
a / b / c ?
Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.
Ouaips. Sauf que lorsque tu travailles dans plusieurs langages qui
sont orthogonaux, tu vas très vite dans le mur.
Par ailleurs, je connais des compilos (gcc pour ne pas le nommer)
qui d'une version à l'autre se comportent différemment.
En d'autres termes, je ne vois pas l'intérêt d'économiser une
parenthèse lorsque cela évite une étape de debug qui peut être assez
laborieuse.
Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
JKB écrivit :Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
JKB écrivit :
Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
JKB écrivit :Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
, le 06/09/2010 a écrit :
[...]Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
[...]comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
Je serais assez d'accord sur le fond de votre intervention, bien que
moins dur que vous. Il y a manifestement dans certaines écritures,
certains C-ismes, un plaisir de chapelle.
Mais les exemples que vous proiposez sont on ne peut plus mal choisis.
Ils ne proposent aucune sorte d'ambiguïté. Ils sont en accord avec
l'arithmétique de base, le bon sens et les habitudes de M. Toulemonde
et sa calculette de chez Auchan. Qui est rarement RPN.
Par curiosité, j'ai regardé dans quels cas un gcc 4.4.1 juste Wall me
proposait une alerte (toujours un warning proposant des parenthèses, en
fait un warning pour suspicion d'erreur, inutile si tous les
programmeurs étaient parfaits).
Rien bien entendu pour
d = a - b - c;
ni:
e = a / b / c;
Un warning attendu dans ce cas:
if(a = b)...
qui se tait avec:
if((a = b) != 0)...
ou simplement (puisque if(a) est admis):
if((a = b))...
Un warning pour:
if(a == b == c)...
Le programmeur a-t-il bien voulu comparer c au résultat de la
comparaison a == b ? Et quand bien même, s'est-il interrogé sur le cas
où c ne vaut ni 0 ni 1 ?
if((a == b) == c)...
fait taire le warning. Je trouve ça presque insuffisant, à moins que c
soit clairement le résultat d'une opération logique. Ecrire plutôt:
if((a == b) == !!c)...
ou carrément (si if(a == b == c) n'était pas une erreur:
if(((a == b) && (c == 1)) || ((a != b) && (c == 0)))...
ou plus léger et que je lis mieux:
if(a == b ? c == 1 : c == 0)...
Enfin, j'ai remarqué que:
a | b & c | d
a & b | c & d
a || b && c || d
a && b || c && d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?
caribou@server.invalid, le 06/09/2010 a écrit :
[...]
Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
[...]
comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
Je serais assez d'accord sur le fond de votre intervention, bien que
moins dur que vous. Il y a manifestement dans certaines écritures,
certains C-ismes, un plaisir de chapelle.
Mais les exemples que vous proiposez sont on ne peut plus mal choisis.
Ils ne proposent aucune sorte d'ambiguïté. Ils sont en accord avec
l'arithmétique de base, le bon sens et les habitudes de M. Toulemonde
et sa calculette de chez Auchan. Qui est rarement RPN.
Par curiosité, j'ai regardé dans quels cas un gcc 4.4.1 juste Wall me
proposait une alerte (toujours un warning proposant des parenthèses, en
fait un warning pour suspicion d'erreur, inutile si tous les
programmeurs étaient parfaits).
Rien bien entendu pour
d = a - b - c;
ni:
e = a / b / c;
Un warning attendu dans ce cas:
if(a = b)...
qui se tait avec:
if((a = b) != 0)...
ou simplement (puisque if(a) est admis):
if((a = b))...
Un warning pour:
if(a == b == c)...
Le programmeur a-t-il bien voulu comparer c au résultat de la
comparaison a == b ? Et quand bien même, s'est-il interrogé sur le cas
où c ne vaut ni 0 ni 1 ?
if((a == b) == c)...
fait taire le warning. Je trouve ça presque insuffisant, à moins que c
soit clairement le résultat d'une opération logique. Ecrire plutôt:
if((a == b) == !!c)...
ou carrément (si if(a == b == c) n'était pas une erreur:
if(((a == b) && (c == 1)) || ((a != b) && (c == 0)))...
ou plus léger et que je lis mieux:
if(a == b ? c == 1 : c == 0)...
Enfin, j'ai remarqué que:
a | b & c | d
a & b | c & d
a || b && c || d
a && b || c && d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?
, le 06/09/2010 a écrit :
[...]Petit quizz : comment sont évaluées :
a - b - c ?
a / b / c ?
P.S: à mon avis, un programmeur écrivant des expressions comme
ci-dessus mérite un magistral coup de pied au cul !
[...]comme tu le fais justement remarquer un peu plus haut, les règles
d'associativité sont dépendantes du langage et donc je reste persuadé qu'un
programmeur qui est capable d'écrire des expressions commmes celles que
j'ai mentionné ci-dessus ne cherche pas à avoir du code facile à maintenir
(même dans plusieurs années) mais juste à montrer sa maîtrise du langage.
J'ai tellement vu de bugs juste parce qu'un programmeur maladroit, croyant
maitriser les subtilités d'un langage, préférait faire "pédant et
compliqué" alors qu'il aurait du faire "simple et clair". Le "obfuscated C
code contest" est une preuve de maitrise indéniable et une activité très
amusante, mais j'aurais de la peine à la recommander pour les vrais
programmes.
Je serais assez d'accord sur le fond de votre intervention, bien que
moins dur que vous. Il y a manifestement dans certaines écritures,
certains C-ismes, un plaisir de chapelle.
Mais les exemples que vous proiposez sont on ne peut plus mal choisis.
Ils ne proposent aucune sorte d'ambiguïté. Ils sont en accord avec
l'arithmétique de base, le bon sens et les habitudes de M. Toulemonde
et sa calculette de chez Auchan. Qui est rarement RPN.
Par curiosité, j'ai regardé dans quels cas un gcc 4.4.1 juste Wall me
proposait une alerte (toujours un warning proposant des parenthèses, en
fait un warning pour suspicion d'erreur, inutile si tous les
programmeurs étaient parfaits).
Rien bien entendu pour
d = a - b - c;
ni:
e = a / b / c;
Un warning attendu dans ce cas:
if(a = b)...
qui se tait avec:
if((a = b) != 0)...
ou simplement (puisque if(a) est admis):
if((a = b))...
Un warning pour:
if(a == b == c)...
Le programmeur a-t-il bien voulu comparer c au résultat de la
comparaison a == b ? Et quand bien même, s'est-il interrogé sur le cas
où c ne vaut ni 0 ni 1 ?
if((a == b) == c)...
fait taire le warning. Je trouve ça presque insuffisant, à moins que c
soit clairement le résultat d'une opération logique. Ecrire plutôt:
if((a == b) == !!c)...
ou carrément (si if(a == b == c) n'était pas une erreur:
if(((a == b) && (c == 1)) || ((a != b) && (c == 0)))...
ou plus léger et que je lis mieux:
if(a == b ? c == 1 : c == 0)...
Enfin, j'ai remarqué que:
a | b & c | d
a & b | c & d
a || b && c || d
a && b || c && d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?
Oui. Il n'y a aucun problème là-dedans. Ce qui est li tigieux, mais
aussi en mathématiques de base, ce sont des expressions comme
a - b - c
puisque le résultat est différent selon l'associativi té. C'est dans
ce cas qu'il faut mettre des parenthèses pour la lisibi lité du
code. On a beau jeu de dire que l'associativité se fait de gauche à
droite. Lorsqu'on a une expression simple, c'est trivial. Lorsque ça
devient un peu plus complexe, c'est tout de suite un nid à problème
qu'on peut facilement éviter !
Oui. Il n'y a aucun problème là-dedans. Ce qui est li tigieux, mais
aussi en mathématiques de base, ce sont des expressions comme
a - b - c
puisque le résultat est différent selon l'associativi té. C'est dans
ce cas qu'il faut mettre des parenthèses pour la lisibi lité du
code. On a beau jeu de dire que l'associativité se fait de gauche à
droite. Lorsqu'on a une expression simple, c'est trivial. Lorsque ça
devient un peu plus complexe, c'est tout de suite un nid à problème
qu'on peut facilement éviter !
Oui. Il n'y a aucun problème là-dedans. Ce qui est li tigieux, mais
aussi en mathématiques de base, ce sont des expressions comme
a - b - c
puisque le résultat est différent selon l'associativi té. C'est dans
ce cas qu'il faut mettre des parenthèses pour la lisibi lité du
code. On a beau jeu de dire que l'associativité se fait de gauche à
droite. Lorsqu'on a une expression simple, c'est trivial. Lorsque ça
devient un peu plus complexe, c'est tout de suite un nid à problème
qu'on peut facilement éviter !
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Le Mon, 06 Sep 2010 14:51:01 +0200,Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Le Mon, 06 Sep 2010 14:51:01 +0200,
Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Le Mon, 06 Sep 2010 14:51:01 +0200,Un warning attendu dans ce cas:
if(a = b)...
Qui est malheureusement parfaitement légal. Je me bats tous les
jours contre ce genre de conneries parce qu'il y a des OS ou NULL ne
vaut pas zéro ! Au hasard VMS avec certaines versions antiques de
DEC C.
Le Mon, 06 Sep 2010 13:51:09 +0200,
Antoine Leca écrivait :JKB écrivit :Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
JKB
Le Mon, 06 Sep 2010 13:51:09 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
JKB écrivit :
Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
JKB
Le Mon, 06 Sep 2010 13:51:09 +0200,
Antoine Leca écrivait :JKB écrivit :Personnellement, lorsque je suis obligé de relire du code avec des
trucs comme :
e = a - b - c + d;
avec des variables qui peuvent être de types différents ou de
valeurs absolues franchement différentes lorsqu'il s'agit de
flottants, je vois rouge et je n'ai même pas envie de rechercher les
autres bugs !
Sauf que là, tu as changé le problème et la possible solution : si tu es
confronté à un souci à cause des types flottants et des arrondis (ou
même tout simplement à cause des types et donc des domaines différents),
la solution ne viendra pas de parenthèses, mais de transtypages et de
réorganisation de l'expression, ou même de décomposer en plusieurs
opérations distinctes.
Et oui, cela peut être un souci avec du code d'analyse numérique en
comportement aux limites ; et il est fort possible que le code ci-dessus
n'ait PAS été testé de manière adéquate : mais j'ai tendance à penser
que si cela devient un objectif, avant de rentrer dans la phase de
débogage de possibles erreurs, on pourrait commencer par une analyse du
problème... qui dans mon cas débouchera sur des commentaires
accompagnant l'expression, voire des assertions validant les hypothèses
attendues (en supposant que l'expression est correcte).
Ça ne change rien au fait que des parenthèses dans le cas
a - b - c
pour avoir
a - (b + c)
est largement plus clair.
JKB