je lis partout le terme "d'associativit=E9" des op=E9rateurs ainsi que le
teme de "priorit=E9" des op=E9rateurs je pense avoir compris celui de la
priorit=E9 mais cette notion d'associativit=E9 reste tr=E8s (trop) floue
pour moi et je ne trouve rien qui l'explique clairement sur le net.
Pour résumer ma position, je suis toujours pour mettre des parenthèses dans les expressions et expliciter TOUTES les conversions (comme ADA l'impose, par exemple).
En C, le fait d'expliciter les conversions a un gros défaut : cela cache (par écrasement, la loi du plus fort quoi) beaucoup d'avertissements qui pourraient parfois être utiles...
En fait, je crois qu'en terme de style, on peut trouver un défaut à toutes les conventions, parce qu'en fait les conventions n'ont de sens que dans un contexte donné (un projet, un certain genre de programmes, en taille ou finalité, une manière de travailler, un compilateur etc.); et que pour un autre programmeur avec un contexte très différent, les dites conventions peuvent devenir... moins bonnes, disons.
Antoine
Wykaaa écrivit :
Pour résumer ma position, je suis toujours pour mettre des parenthèses
dans les expressions et expliciter TOUTES les conversions (comme ADA
l'impose, par exemple).
En C, le fait d'expliciter les conversions a un gros défaut :
cela cache (par écrasement, la loi du plus fort quoi) beaucoup
d'avertissements qui pourraient parfois être utiles...
En fait, je crois qu'en terme de style, on peut trouver un défaut à
toutes les conventions, parce qu'en fait les conventions n'ont de sens
que dans un contexte donné (un projet, un certain genre de programmes,
en taille ou finalité, une manière de travailler, un compilateur etc.);
et que pour un autre programmeur avec un contexte très différent, les
dites conventions peuvent devenir... moins bonnes, disons.
Pour résumer ma position, je suis toujours pour mettre des parenthèses dans les expressions et expliciter TOUTES les conversions (comme ADA l'impose, par exemple).
En C, le fait d'expliciter les conversions a un gros défaut : cela cache (par écrasement, la loi du plus fort quoi) beaucoup d'avertissements qui pourraient parfois être utiles...
En fait, je crois qu'en terme de style, on peut trouver un défaut à toutes les conventions, parce qu'en fait les conventions n'ont de sens que dans un contexte donné (un projet, un certain genre de programmes, en taille ou finalité, une manière de travailler, un compilateur etc.); et que pour un autre programmeur avec un contexte très différent, les dites conventions peuvent devenir... moins bonnes, disons.
Antoine
Samuel DEVULDER
Le 14/09/2010 12:48, Wykaaa a écrit :
Pour résumer ma position, je suis toujours pour mettre des parenthèses dans les expressions et expliciter TOUTES les conversions (comme ADA l'impose, par exemple).
C'est pas tellement les conversions qui sont mauvaise, mais le fait qu'elles sont faite sans qu'on en ait conscience. Certains bugs viennent de trucs qui sont fait à l'insu du programmeur, implicitement, par le langage ou le compilateur. D'une façon générale, plus on est explicite, moins on évite de soucis sur le long terme.
sam.
Le 14/09/2010 12:48, Wykaaa a écrit :
Pour résumer ma position, je suis toujours pour mettre des parenthèses
dans les expressions et expliciter TOUTES les conversions (comme ADA
l'impose, par exemple).
C'est pas tellement les conversions qui sont mauvaise, mais le fait
qu'elles sont faite sans qu'on en ait conscience. Certains bugs viennent
de trucs qui sont fait à l'insu du programmeur, implicitement, par le
langage ou le compilateur. D'une façon générale, plus on est explicite,
moins on évite de soucis sur le long terme.
Pour résumer ma position, je suis toujours pour mettre des parenthèses dans les expressions et expliciter TOUTES les conversions (comme ADA l'impose, par exemple).
C'est pas tellement les conversions qui sont mauvaise, mais le fait qu'elles sont faite sans qu'on en ait conscience. Certains bugs viennent de trucs qui sont fait à l'insu du programmeur, implicitement, par le langage ou le compilateur. D'une façon générale, plus on est explicite, moins on évite de soucis sur le long terme.
sam.
Antoine Leca
Samuel DEVULDER écrivit :
C'est pas tellement les conversions qui sont mauvaise
Je n'ai pas vu que quelqu'un ait dit cela.
mais le fait qu'elles sont faite sans qu'on en ait conscience.
Oui, c'est un trait caractéristique de C. D'aucuns pensent que c'est un avantage, autrement dit que C se situe au juste niveau d'abstraction. On est évidemment en droit de contester.
plus on est explicite, moins on évite de soucis sur le long terme.
Es-tu sûr que c'est ce que tu voulais écrire ?
Autant je peux accepter que l'on puisse proposer la position contraire (moins explicite => on évite plus de souci, moins de problème), même si je ne suis pas d'accord, autant en ce qui concerne ta position je ne comprend pas le lien (plus explicite => plus de problème). Peux-tu en expliquer le raisonnement ?
Antoine
Samuel DEVULDER écrivit :
C'est pas tellement les conversions qui sont mauvaise
Je n'ai pas vu que quelqu'un ait dit cela.
mais le fait qu'elles sont faite sans qu'on en ait conscience.
Oui, c'est un trait caractéristique de C. D'aucuns pensent que c'est un
avantage, autrement dit que C se situe au juste niveau d'abstraction.
On est évidemment en droit de contester.
plus on est explicite, moins on évite de soucis sur le long terme.
Es-tu sûr que c'est ce que tu voulais écrire ?
Autant je peux accepter que l'on puisse proposer la position contraire
(moins explicite => on évite plus de souci, moins de problème), même si
je ne suis pas d'accord, autant en ce qui concerne ta position je ne
comprend pas le lien (plus explicite => plus de problème). Peux-tu en
expliquer le raisonnement ?
C'est pas tellement les conversions qui sont mauvaise
Je n'ai pas vu que quelqu'un ait dit cela.
mais le fait qu'elles sont faite sans qu'on en ait conscience.
Oui, c'est un trait caractéristique de C. D'aucuns pensent que c'est un avantage, autrement dit que C se situe au juste niveau d'abstraction. On est évidemment en droit de contester.
plus on est explicite, moins on évite de soucis sur le long terme.
Es-tu sûr que c'est ce que tu voulais écrire ?
Autant je peux accepter que l'on puisse proposer la position contraire (moins explicite => on évite plus de souci, moins de problème), même si je ne suis pas d'accord, autant en ce qui concerne ta position je ne comprend pas le lien (plus explicite => plus de problème). Peux-tu en expliquer le raisonnement ?
Antoine
Samuel DEVULDER
Le 15/09/2010 09:04, Antoine Leca a écrit :
plus on est explicite, moins on évite de soucis sur le long terme.
^^^^ ^^^^^
autant en ce qui concerne ta position je ne
comprend pas le lien (plus explicite => plus de problème). Peux-tu en expliquer le raisonnement ?
Oui j'ai merdé. "plus on est explicite, moins il y a de soucis". ;-)
C'est de la faute du C que je me goure. La double négation y est en fait une pre-decrementation: --x :-p
sam (whaaa l'excuse à 2 balles)
Le 15/09/2010 09:04, Antoine Leca a écrit :
plus on est explicite, moins on évite de soucis sur le long terme.
^^^^ ^^^^^
autant en ce qui concerne ta position je ne
comprend pas le lien (plus explicite => plus de problème). Peux-tu en
expliquer le raisonnement ?
Oui j'ai merdé. "plus on est explicite, moins il y a de soucis". ;-)
C'est de la faute du C que je me goure. La double négation y est en fait
une pre-decrementation: --x :-p
plus on est explicite, moins on évite de soucis sur le long terme.
^^^^ ^^^^^
autant en ce qui concerne ta position je ne
comprend pas le lien (plus explicite => plus de problème). Peux-tu en expliquer le raisonnement ?
Oui j'ai merdé. "plus on est explicite, moins il y a de soucis". ;-)
C'est de la faute du C que je me goure. La double négation y est en fait une pre-decrementation: --x :-p
sam (whaaa l'excuse à 2 balles)
Vincent Lefevre
Dans l'article <4c8f4f39$0$12643$, Samuel DEVULDER écrit:
Le 14/09/2010 11:29, Vincent Lefevre a écrit :
> iRRAM sait représenter sqrt(2), sqrt(5)... exactement: par un programme.
Oui sauf que sa représentation se limite au calcul numérique. Il ne sait pas manipuler symboliquement sqrt(2). Typiquement la valeur du test sqrt(2)*sqrt(2) == 2 lui est à tout jamais inconnue. Il peut juste approximer 2.000000000... sans jamais en être sur que ce soit exactement 2: il part en boucle infinie. Pour éviter cela il faudrait travailler au niveau supérieur, "méta", et voir que la limite du calcul de l'algo sqrt(x) multiplié par lui même est exactement x quel que soit ce dernier nombre (positif tout de même).
Oui, mais c'est un problème d'algorithme, pas de représentation.
> C'est la même chose en math: sqrt(2) est représenté exactement par > une expression: sqrt(2). On peut faire des calculs plus puisssants > qu'avec iRRAM. Mais certains problèmes restent indécidables.
Ca pose la question de fond qui est limite philosophique. Qu'est ce que sqrt(2) ? Une valeur symbolique munie de quelques propriétés? Une valeur numérique infiniment approximables? Une suite de rationnels qui converge vers lui et dont les termes pairs et impairs l'encadrent? La suite de ses chiffres dans son développement décimal? La suite des entiers utilisés dans son développement en fraction continue? Un élément de l'extension algèbrique de RootOf(X^2-2)?
sqrt(2), en tant que suite de caractères, est une expression, et cette expression représente un élément particulier de R (l'ensemble des réels) par exemple.
Dans l'article <4c8f4f39$0$12643$426a74cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> écrit:
Le 14/09/2010 11:29, Vincent Lefevre a écrit :
> iRRAM sait représenter sqrt(2), sqrt(5)... exactement: par un programme.
Oui sauf que sa représentation se limite au calcul numérique. Il ne sait
pas manipuler symboliquement sqrt(2). Typiquement la valeur du test
sqrt(2)*sqrt(2) == 2 lui est à tout jamais inconnue. Il peut juste
approximer 2.000000000... sans jamais en être sur que ce soit exactement
2: il part en boucle infinie. Pour éviter cela il faudrait travailler au
niveau supérieur, "méta", et voir que la limite du calcul de l'algo
sqrt(x) multiplié par lui même est exactement x quel que soit ce dernier
nombre (positif tout de même).
Oui, mais c'est un problème d'algorithme, pas de représentation.
> C'est la même chose en math: sqrt(2) est représenté exactement par
> une expression: sqrt(2). On peut faire des calculs plus puisssants
> qu'avec iRRAM. Mais certains problèmes restent indécidables.
Ca pose la question de fond qui est limite philosophique. Qu'est ce que
sqrt(2) ? Une valeur symbolique munie de quelques propriétés? Une valeur
numérique infiniment approximables? Une suite de rationnels qui converge
vers lui et dont les termes pairs et impairs l'encadrent? La suite de
ses chiffres dans son développement décimal? La suite des entiers
utilisés dans son développement en fraction continue? Un élément de
l'extension algèbrique de RootOf(X^2-2)?
sqrt(2), en tant que suite de caractères, est une expression,
et cette expression représente un élément particulier de R
(l'ensemble des réels) par exemple.
Dans l'article <4c8f4f39$0$12643$, Samuel DEVULDER écrit:
Le 14/09/2010 11:29, Vincent Lefevre a écrit :
> iRRAM sait représenter sqrt(2), sqrt(5)... exactement: par un programme.
Oui sauf que sa représentation se limite au calcul numérique. Il ne sait pas manipuler symboliquement sqrt(2). Typiquement la valeur du test sqrt(2)*sqrt(2) == 2 lui est à tout jamais inconnue. Il peut juste approximer 2.000000000... sans jamais en être sur que ce soit exactement 2: il part en boucle infinie. Pour éviter cela il faudrait travailler au niveau supérieur, "méta", et voir que la limite du calcul de l'algo sqrt(x) multiplié par lui même est exactement x quel que soit ce dernier nombre (positif tout de même).
Oui, mais c'est un problème d'algorithme, pas de représentation.
> C'est la même chose en math: sqrt(2) est représenté exactement par > une expression: sqrt(2). On peut faire des calculs plus puisssants > qu'avec iRRAM. Mais certains problèmes restent indécidables.
Ca pose la question de fond qui est limite philosophique. Qu'est ce que sqrt(2) ? Une valeur symbolique munie de quelques propriétés? Une valeur numérique infiniment approximables? Une suite de rationnels qui converge vers lui et dont les termes pairs et impairs l'encadrent? La suite de ses chiffres dans son développement décimal? La suite des entiers utilisés dans son développement en fraction continue? Un élément de l'extension algèbrique de RootOf(X^2-2)?
sqrt(2), en tant que suite de caractères, est une expression, et cette expression représente un élément particulier de R (l'ensemble des réels) par exemple.
