Alexandre Bacquart écrivit :a - b - c
L'expression en tant que telle n'a rien à voir avec l'associativité, que
ce soit en maths ou en C. La seule règle à suivre est que ça s'applique
de gauche à droite.
Mmmm. Et le fait que lire de gauche à droite puisse donner le même
résultat que lire de droite à gauche, cela s'appelle comment, en maths ?
Autrement dit, parce que - n'est évidemment pas une opération
associative, tu as besoin d'une règle _conventionnelle_, en l'occurrence
qu'il faille lire de gauche à droite.moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.
La position de JKB, c'est justement le rejet de la règle de la lecture
de gauche à droite, et son corrolaire, l'utilisation d'une _autre_
règle, celle des parenthèses : mais il ne s'agit pas d'une règle
supplémentaire, elle remplace.
ce qu'on appelle du code auto-documenté.
Pour moi, le « code auto-documenté » à base de constructions implicites
est une lubie qui cache beaucoup de paresse de la part des programmeurs
et induit beaucoup de perte de temps pour des questions existentielles
au moment de la phase débogage ; là où c'est drôle, c'est quand il se
trouve que la même personne est à la fois le programmeur auto-
documentant et celui qui se pose des questions au débogage ;-)
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Alexandre Bacquart écrivit :
a - b - c
L'expression en tant que telle n'a rien à voir avec l'associativité, que
ce soit en maths ou en C. La seule règle à suivre est que ça s'applique
de gauche à droite.
Mmmm. Et le fait que lire de gauche à droite puisse donner le même
résultat que lire de droite à gauche, cela s'appelle comment, en maths ?
Autrement dit, parce que - n'est évidemment pas une opération
associative, tu as besoin d'une règle _conventionnelle_, en l'occurrence
qu'il faille lire de gauche à droite.
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.
La position de JKB, c'est justement le rejet de la règle de la lecture
de gauche à droite, et son corrolaire, l'utilisation d'une _autre_
règle, celle des parenthèses : mais il ne s'agit pas d'une règle
supplémentaire, elle remplace.
ce qu'on appelle du code auto-documenté.
Pour moi, le « code auto-documenté » à base de constructions implicites
est une lubie qui cache beaucoup de paresse de la part des programmeurs
et induit beaucoup de perte de temps pour des questions existentielles
au moment de la phase débogage ; là où c'est drôle, c'est quand il se
trouve que la même personne est à la fois le programmeur auto-
documentant et celui qui se pose des questions au débogage ;-)
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Alexandre Bacquart écrivit :a - b - c
L'expression en tant que telle n'a rien à voir avec l'associativité, que
ce soit en maths ou en C. La seule règle à suivre est que ça s'applique
de gauche à droite.
Mmmm. Et le fait que lire de gauche à droite puisse donner le même
résultat que lire de droite à gauche, cela s'appelle comment, en maths ?
Autrement dit, parce que - n'est évidemment pas une opération
associative, tu as besoin d'une règle _conventionnelle_, en l'occurrence
qu'il faille lire de gauche à droite.moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.
La position de JKB, c'est justement le rejet de la règle de la lecture
de gauche à droite, et son corrolaire, l'utilisation d'une _autre_
règle, celle des parenthèses : mais il ne s'agit pas d'une règle
supplémentaire, elle remplace.
ce qu'on appelle du code auto-documenté.
Pour moi, le « code auto-documenté » à base de constructions implicites
est une lubie qui cache beaucoup de paresse de la part des programmeurs
et induit beaucoup de perte de temps pour des questions existentielles
au moment de la phase débogage ; là où c'est drôle, c'est quand il se
trouve que la même personne est à la fois le programmeur auto-
documentant et celui qui se pose des questions au débogage ;-)
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Wykaaa écrivit :Exemples pour l'associativité :
- Associativité à gauche de l'opérateur + binaire :
a + b + c + d s'interprète comme : (((a + b) + c ) + d)
- Associativité à droite de l'opérateur d'affectation :
a = b = c = d s'interprète comme : (a = (b = (c = d)))
OuiIl est conseillé de TOUJOURS mettre les parenthèses dans les expressions.
Mmmm, je ne suis pas complétement d'accord là. Cf. infra.Priorité des opérateurs :
- La multiplication est prioritaire par rapport à l'addition. Ceci
signifie que : a + b * c s'interprète comme : a + (b * c)
Oui- attention à certains cas :
OUI. Et c'est là que je vois l'intérêt de mettre des parenthèses, MÊME
si elles ne sont pas strictement nécessaires : en effet les cas d'erreur
potentielles sont nombreux en C.
Cela concerne les opérateurs sur les valeurs binaires (& | ^), les
opérateurs de décalages (<< >>) et les opérateurs de comparaison.
Que j'ai exprès mis dans le désordre.l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
J'ai vu je ne sais combien de fois cette erreur en faisant des revues de
code (et pas seulement en C, C++ ou Java mais aussi en PL/1, par exemple).
Antoine
Wykaaa écrivit :
Exemples pour l'associativité :
- Associativité à gauche de l'opérateur + binaire :
a + b + c + d s'interprète comme : (((a + b) + c ) + d)
- Associativité à droite de l'opérateur d'affectation :
a = b = c = d s'interprète comme : (a = (b = (c = d)))
Oui
Il est conseillé de TOUJOURS mettre les parenthèses dans les expressions.
Mmmm, je ne suis pas complétement d'accord là. Cf. infra.
Priorité des opérateurs :
- La multiplication est prioritaire par rapport à l'addition. Ceci
signifie que : a + b * c s'interprète comme : a + (b * c)
Oui
- attention à certains cas :
OUI. Et c'est là que je vois l'intérêt de mettre des parenthèses, MÊME
si elles ne sont pas strictement nécessaires : en effet les cas d'erreur
potentielles sont nombreux en C.
Cela concerne les opérateurs sur les valeurs binaires (& | ^), les
opérateurs de décalages (<< >>) et les opérateurs de comparaison.
Que j'ai exprès mis dans le désordre.
l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
J'ai vu je ne sais combien de fois cette erreur en faisant des revues de
code (et pas seulement en C, C++ ou Java mais aussi en PL/1, par exemple).
Antoine
Wykaaa écrivit :Exemples pour l'associativité :
- Associativité à gauche de l'opérateur + binaire :
a + b + c + d s'interprète comme : (((a + b) + c ) + d)
- Associativité à droite de l'opérateur d'affectation :
a = b = c = d s'interprète comme : (a = (b = (c = d)))
OuiIl est conseillé de TOUJOURS mettre les parenthèses dans les expressions.
Mmmm, je ne suis pas complétement d'accord là. Cf. infra.Priorité des opérateurs :
- La multiplication est prioritaire par rapport à l'addition. Ceci
signifie que : a + b * c s'interprète comme : a + (b * c)
Oui- attention à certains cas :
OUI. Et c'est là que je vois l'intérêt de mettre des parenthèses, MÊME
si elles ne sont pas strictement nécessaires : en effet les cas d'erreur
potentielles sont nombreux en C.
Cela concerne les opérateurs sur les valeurs binaires (& | ^), les
opérateurs de décalages (<< >>) et les opérateurs de comparaison.
Que j'ai exprès mis dans le désordre.l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
J'ai vu je ne sais combien de fois cette erreur en faisant des revues de
code (et pas seulement en C, C++ ou Java mais aussi en PL/1, par exemple).
Antoine
largement plus probable en l'instance) ; mais c'est aussi une chose qui
va surprendre la plupart des « utilisateurs », autrement dit cela
ressemble à de la mauvaise qualité...
largement plus probable en l'instance) ; mais c'est aussi une chose qui
va surprendre la plupart des « utilisateurs », autrement dit cela
ressemble à de la mauvaise qualité...
largement plus probable en l'instance) ; mais c'est aussi une chose qui
va surprendre la plupart des « utilisateurs », autrement dit cela
ressemble à de la mauvaise qualité...
In article <4c86b5c7$0$22645$,
Samuel DEVULDER wrote:Le 07/09/2010 01:53, Marc Espie a écrit :Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),
Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?
Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.
ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)
Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.
Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.
On va plutot dire, incomprehensible pour le programmeur java moyen, hein...
In article <4c86b5c7$0$22645$426a34cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> wrote:
Le 07/09/2010 01:53, Marc Espie a écrit :
Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),
Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?
Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.
ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)
Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.
Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.
On va plutot dire, incomprehensible pour le programmeur java moyen, hein...
In article <4c86b5c7$0$22645$,
Samuel DEVULDER wrote:Le 07/09/2010 01:53, Marc Espie a écrit :Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),
Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?
Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.
ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)
Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.
Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.
On va plutot dire, incomprehensible pour le programmeur java moyen, hein...
Antoine Leca a écrit :Wykaaa écrivit :Priorité des opérateurs :
l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
Oui et bien quoi en C ?
Un exemple d'utilisation :
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
Ben c'est l'utilisation la plus courante.
Je ne vois pas ce qu'il y a de
surprenant à cela et, pour une fois, DMR a raison.
Antoine Leca a écrit :
Wykaaa écrivit :
Priorité des opérateurs :
l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
Oui et bien quoi en C ?
Un exemple d'utilisation :
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
Ben c'est l'utilisation la plus courante.
Je ne vois pas ce qu'il y a de
surprenant à cela et, pour une fois, DMR a raison.
Antoine Leca a écrit :Wykaaa écrivit :Priorité des opérateurs :
l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
a + b & c s'interprète comme a + (b & c)
En mathématiques (où & est un succédané de multiplication) ou en Turbo
Pascal (avec & écrit and) d'accord, mais en C ?
Oui et bien quoi en C ?
Un exemple d'utilisation :
En général, ce que souhaite le programmeur, c'est plutôt faire :
(a + b) & c (appliquer un "masque" au résultat de l'addition).
Là, c'est la justification du choix de DMR...
Ben c'est l'utilisation la plus courante.
Je ne vois pas ce qu'il y a de
surprenant à cela et, pour une fois, DMR a raison.
Notez que je ne fais qu'insister sur le contenu de mon précédent message
: si le code dépend de la première forme et ne passe pas avec la seconde
(ou vice-versa), il faut rajouter des commentaires pour éviter de se
poser des questions existentielles.
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Notez que je ne fais qu'insister sur le contenu de mon précédent message
: si le code dépend de la première forme et ne passe pas avec la seconde
(ou vice-versa), il faut rajouter des commentaires pour éviter de se
poser des questions existentielles.
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Notez que je ne fais qu'insister sur le contenu de mon précédent message
: si le code dépend de la première forme et ne passe pas avec la seconde
(ou vice-versa), il faut rajouter des commentaires pour éviter de se
poser des questions existentielles.
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.
Le Wed, 08 Sep 2010 11:20:19 +0200,
Antoine Leca écrivait :La position de JKB, c'est [...]
Attention, on commence à toucher du doigt un consensus ;-)
ce qu'on appelle du code auto-documenté.
Pour moi, [...] je crois [...]
Je plussoie vigoureusement.
Le Wed, 08 Sep 2010 11:20:19 +0200,
Antoine Leca <root@localhost.invalid> écrivait :
La position de JKB, c'est [...]
Attention, on commence à toucher du doigt un consensus ;-)
ce qu'on appelle du code auto-documenté.
Pour moi, [...] je crois [...]
Je plussoie vigoureusement.
Le Wed, 08 Sep 2010 11:20:19 +0200,
Antoine Leca écrivait :La position de JKB, c'est [...]
Attention, on commence à toucher du doigt un consensus ;-)
ce qu'on appelle du code auto-documenté.
Pour moi, [...] je crois [...]
Je plussoie vigoureusement.
Wykaaa écrivit :Antoine Leca a écrit :Wykaaa écrivit :Priorité des opérateurs :
[couic]l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
Jusqu'à maintenant, j'avais considéré que les opérations arithmétiques
(+ - * / %) étaient plus prioritaires que l'opérateur &.
Wykaaa écrivit :
Antoine Leca a écrit :
Wykaaa écrivit :
Priorité des opérateurs :
[couic]
l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
Jusqu'à maintenant, j'avais considéré que les opérations arithmétiques
(+ - * / %) étaient plus prioritaires que l'opérateur &.
Wykaaa écrivit :Antoine Leca a écrit :Wykaaa écrivit :Priorité des opérateurs :
[couic]l'opérateur & (opérateur ET bit à bit) est
plus prioritaire que les opérations arithmétiques
? On est bien sur fr.comp.lang.c ?
Je ne comprends pas ton interrogation. Oui c'est du C !
Jusqu'à maintenant, j'avais considéré que les opérations arithmétiques
(+ - * / %) étaient plus prioritaires que l'opérateur &.
