Beuuurk !

Miod Vallat <miod@online.fr> écrivait :

Et quoi que tu dises, sur ce point, le langage C ne se classe pas la
catégorie des langages fournis avec planche savonnée au savon noir.

Sauf les opérateurs binaires (&,|, ^) de priorité supérieure aux
opérateurs de test...

Ça c'est une vraie planche savonnée. Heureusement beaucoup de
compilateurs mettent un warning quand l'expression n'est pas
parenthésée, mais ils ne sont pas obligés.

--
Real programs don't eat cache

On Mon, 26 Apr 2004 13:57:09 +0000 (UTC)
espie@tetto.gentiane.org (Marc Espie) wrote:

Le gars qui n'a pas fait d'etudes, et qui n'est pas autodidacte
genial, il va avoir beaucoup, beaucoup de mal a comprendre certains
trucs par lui-meme. C'est la realite, ca n'est pas moi qui en
decide.

J'en connais qui ont fait des etudes et qui ne se debrouillent pas mieux.

La ou je trouve que ca devient dangereux, c'est quand on va confier
a ce type (qui a dix ans d'experience) du code critique qui se
trouvera dans cette frange d'algorithmes qu'il ne comprend pas.

Voir ci-dessus.

Et la ou je trouve que c'est absurde, c'est quand il va se retrouver
a se demener trois heures pour reinventer une roue tordue alors que
la belle roue bien ronde vient `naturellement' avec les bonnes
bases.

Tu n'as pas du voir beaucoup de projets sortant de bureaux d'etudes :/

[COUIC]

A cote de ca, j'ai decouvert pas mal de trucs par moi-meme, ou j'ai
bute sur pas mal de choses qui m'ont rendu les notions mathematiques
ou informatiques vues ensuite interessantes. La notion de
dichotomie, par exemple, que j'ai presque retrouvee en resolvant des
equations; ou la notion de section critique, que j'ai trouve en
reparant le pilote d'imprimante de ma seikosha GP100 qui begayait...
mais je ne regrette
absolument pas d'avoir vu ensuite le formalisme correspondant.

Je pourrais dire idem pour moi (avec par exemple des equations
d'affichage 3D que j'ai retrouvees presque 10 ans plus tard en BTS).
Le formalisme me manque surement mais je me rend compte quand meme que
certaines personnes qui ont eu ce formalisme ont quand meme du mal.

mips

On Mon, 26 Apr 2004 15:03:25 +0000 (UTC)
pornin@nerim.net (Thomas Pornin) wrote:

According to mips <mips@cyberspace.org>:

Pour moi un source lisible est un source qui se comprend du
premier coup d'oeil. Or ce genre de construction je ne fais pas
qu'y jeter qu'un coup d'oeil vu qu'il est si facile de se
meprendre.

Un code source est lisible s'il est facilement compris en le lisant.
C'est une tautologie. Mais il faut bien prendre conscience que la
lisibilité dépend beaucoup de celui qui lit, et qu'on suppose
toujours une base de connaissance de la part du lecteur, fût-ce
implicitement.

On est d'accord.

En l'occurrence, quand on montre un code source en C à un lecteur,
on suppose que ce lecteur saura suffisamment de C pour en faire
quelque chose. Il y a pas mal de choses en C qui ne sont pas
évidentes du tout pour celui qui n'en a jamais appris la syntaxe,

Oui mais la on ne parle pas de neophytes en C. On parle du fait qu'un
meme code peut etre formate de differentes facons. Et que ce formatage
peut-etre plus ou moins obscur et donc etre source d'erreur ou de
mauvaise comprehension.

mips

According to mips <mips@cyberspace.org>:

Oui mais la on ne parle pas de neophytes en C. On parle du fait qu'un
meme code peut etre formate de differentes facons.

Ah, je croyais qu'on parlait de l'évaluation paresseuse par les
opérateurs && et ||. En fait, on était juste dans le pinaillage
usuel sur l'emplacement des accolades.

Plutôt que de répéter toujours les mêmes arguments, vous devriez tous
aller lire :
1. le fichier "linux/Documentation/CodingStyle" dans les source d'un
noyau Linux quelconque ;
2. les "GNU coding standards" : http://www.gnu.org/prep/standards_toc.html
(bien que le fichier précédent invite à ne _pas_ les lire) ;
3. les divers exemples présentés dans le K&R.

Et ensuite, plutôt que de prêter allégeance à l'une de ces différentes
religions, essayez de réfléchir par vous-même.


--Thomas Pornin

On Mon, 26 Apr 2004 21:11:23 +0200
mips <anti@spam.gov> wrote:

On Mon, 26 Apr 2004 13:57:09 +0000 (UTC)
espie@tetto.gentiane.org (Marc Espie) wrote:

Le gars qui n'a pas fait d'etudes, et qui n'est pas autodidacte
genial, il va avoir beaucoup, beaucoup de mal a comprendre certains
trucs par lui-meme. C'est la realite, ca n'est pas moi qui en
decide.

J'en connais qui ont fait des etudes et qui ne se debrouillent pas
mieux.

Je te dirais par expérience d'enseignant, que c'est parce que les
étudiants ont suivi un cours "important" qui est sencé leur servir
partout (genre cours de logique, info théoriqie,
interprétation/compilation ... ) qu'ils ne l'ont pas oublié après l'exam
... mais bon, on ne peut pas lutter contre les bachoteurs et compagnie
...

Et la ou je trouve que c'est absurde, c'est quand il va se retrouver
a se demener trois heures pour reinventer une roue tordue alors que
la belle roue bien ronde vient `naturellement' avec les bonnes
bases.

Tu n'as pas du voir beaucoup de projets sortant de bureaux d'etudes :/

cf audessus (moi aussi je fait du self-referecing ;)

Je pourrais dire idem pour moi (avec par exemple des equations
d'affichage 3D que j'ai retrouvees presque 10 ans plus tard en BTS).
Le formalisme me manque surement mais je me rend compte quand meme que
certaines personnes qui ont eu ce formalisme ont quand meme du mal.

Ce n'est pas seulement un problème de formalisme et de connaissance ...

Un langage de programmation a un minimum de sémantique, même si celle-ci
n'est pas formelle. Il y a des bases et des choses qui sont commune à
tous les langages corrects (comment ça, ce que je dis soutend que pascal
n'est pas correct ... ;) Les opérateurs feignants comme les && et les ||
ont font partie.

Je peux par contre, comprendre certaines critiques sur du code genre
while(i--)(ce genre de machin, prete toujours à confusion, contrairement
au cas précédant, où c'est relativement clair, ici il faut toujours bien
regarder pour voir si c'est un --i ou i-- ce qui ne se voit pas dans une
lecture en diagonale ... )

Maitenant, j'aurais tendance à dire qu'il ne vaut mieux pas toucher au C
(ou à des langages du même genre) lorsque l'on a pas un minimum de
compréhension de ce qu'il se passe derrière. Je m'explique, lorsque l'on
écrit du code qui touche un minimum à la mémoire (ce qui arrive très
rapidement en C, genre, dès que l'on a dépassé le stade du hello world)
la plus part des problèmes (mise à part les étouderies) que l'on
rencontre sont liés à une mauvaise gestion de celle-ci. Or, si l'on ne
comprend pas un minimum la tête du résultat après compilation (notamment
la façon dont les envirronnements de fonction sont gérés par exemple) on
se retrouve avec du code qui paraît par fois pas trop mal, mais qui
pourtant peut être très dangereux ... Il suffit de voir la quantité de
bof qui sort régulièrement, dont certains sont toujours des cas très
"bateau" (genre strcopy et compagnie ... ) pour se rendre compte du
danger que cela représente ...

Alors pinailler sur la lisibilité des && et || vs un if imbriqué ... si
on a du mal à lire ce genre de code ... je dirais qu'il vaut mieux
arreter tout de suite, reprendre un bon (un très bon) cours de C ou
changer de langage (tant qu'à faire, du fonctionnel ;)

Maintenant, hein, tout ça, ça sent le troll, malheureusement ...

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)

On Sat, 24 Apr 2004 18:29:59 +0200
mips <anti@spam.gov> wrote:

Comme quoi manipuler ce genre d'expression en faisant attention aux
effets de bord est loin d'être trivial.
Ce qui tombe pile poil dans mon discours.

Ben, non, justement ...

On a un cas parfait d'une simplification hâtive.

Si tu regarde ça directement dans les yeux, tu as évalue moi ça, si
c'est bon évalue moi ça. Et pas un "ou" ou un "et" logique.

C'est bien pour ça qu'il y a '&' et '&&' (et '|' et '||') dans la plus
part des langages, les deux non pas le même sens (mais reste
distinguable à la lecture, contrairement à la différence entre i-- et
--i ... )

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)

On Tue, 27 Apr 2004 10:47:07 +0200
Marwan Burelle <burelle@lri.fr> wrote:

Maitenant, j'aurais tendance à dire qu'il ne vaut mieux pas toucher
au C(ou à des langages du même genre) lorsque l'on a pas un minimum
de compréhension de ce qu'il se passe derrière. Je m'explique,
lorsque l'onécrit du code qui touche un minimum à la mémoire (ce qui
arrive très rapidement en C, genre, dès que l'on a dépassé le stade
du hello world) la plus part des problèmes (mise à part les
étouderies) que l'on rencontre sont liés à une mauvaise gestion de
celle-ci. Or, si l'on ne comprend pas un minimum la tête du résultat
après compilation (notamment la façon dont les envirronnements de
fonction sont gérés par exemple) on se retrouve avec du code qui
paraît par fois pas trop mal, mais qui pourtant peut être très
dangereux ... Il suffit de voir la quantité de bof qui sort
régulièrement, dont certains sont toujours des cas très"bateau"
(genre strcopy et compagnie ... ) pour se rendre compte du danger
que cela représente ...

A priori je ne me suis mal fait comprendre car tu es le deuxieme a
passer a cote de mon discours.

Je ne me positionne pas dans le cas du neophyte qui se prend un manche
de pioche dans la gueule en faisant ses debuts avec le language C. Je
suis plutot dans le cas du gars qui a deja plusieures annees
d'experience derriere lui et qui fait de la maintenance de code. Et
quand on se tape quelques centaines de lignes de code il me semble
impensable de ne pas avoir a revenir plusieurs fois sur certaines
parties du code a cause de leur formatage (que je traite d'illisible).

Malgre certains propos j'ai vraiment un gros doute sur l'existence de
"terminators" du language C qui puissent se taper et surtout
comprendre parfaitement des centaines de lignes de code en une seule
passe.

Alors pinailler sur la lisibilité des && et || vs un if imbriqué ...
si on a du mal à lire ce genre de code ... je dirais qu'il vaut
mieux arreter tout de suite, reprendre un bon (un très bon) cours de
C ou changer de langage (tant qu'à faire, du fonctionnel ;)

C'etait juste une perche pour parler de la lisibilite du code C en
general. Maintenant je peux te trouver des lignes avec quelques
operateurs imbriques qui auraient vite fait de te faire reflechir a
deux fois avant de dire ce que ca effectue.

Maintenant, hein, tout ça, ça sent le troll, malheureusement ...

Oh, si peu ;)

mips

On Tue, 27 Apr 2004 13:41:50 +0200
mips <anti@spam.gov> wrote:

Je ne me positionne pas dans le cas du neophyte qui se prend un manche
de pioche dans la gueule en faisant ses debuts avec le language C. Je
suis plutot dans le cas du gars qui a deja plusieures annees
d'experience derriere lui et qui fait de la maintenance de code. Et
quand on se tape quelques centaines de lignes de code il me semble
impensable de ne pas avoir a revenir plusieurs fois sur certaines
parties du code a cause de leur formatage (que je traite d'illisible).

Mais j'ai bien compris ... mais ce que l'on te dis, c'est que justement,
la sémantique des opérateurs feignants est clair. Il faut juste la lire
de la bonne façon.

Enfin, pour moi, ce n'est pas franchement un exemple particulier de code
illisible.

Malgre certains propos j'ai vraiment un gros doute sur l'existence de
"terminators" du language C qui puissent se taper et surtout
comprendre parfaitement des centaines de lignes de code en une seule
passe.

On ne parle pas de lire des centaines de lignes en une seule passe. Par
contre, une trentaine ... mais bien sûr, si tous les cas où l'on aurait
pu utiliser un || ou un && on a utilisé un double if, on voit plus grand
chose dans 30 lignes. Enfin, pour moi un code plus "long" n'est pas
forcément plus lisible (en plus dans le cas du double if, on se retrouve
avec une hierarchie de "if" suffisament ambigue, pour justement rendre
les choses moins lisible.)

Maintenant, comme je l'ai dit, ça dépend de ce que tu utilises.
Typiquement, le while (--i) pour savoir ce qui se passe ... en une seule
passe ...

C'etait juste une perche pour parler de la lisibilite du code C en
general. Maintenant je peux te trouver des lignes avec quelques
operateurs imbriques qui auraient vite fait de te faire reflechir a
deux fois avant de dire ce que ca effectue.

Le truc, c'est que je ne suis pas sûr que des if imbriqués se soient
tellement plus lisible (en fait, personnellement, malgrès l'indentation,
une série de if imbriqués fait partie des trucs que je considère comme
dure à lire.) Mais vision personnelle est de réduire le bruit pour
rendre un code lisible autant que d'éviter les expressions bourrées
d'effets de bord, d'autant plus que dans le cas qui nous interesse, il
n'y a pas réellement d'effet de bord.

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)

On Tue, 27 Apr 2004 15:29:49 +0200
Marwan Burelle <burelle@lri.fr> wrote:

Mais j'ai bien compris ... mais ce que l'on te dis, c'est que
justement, la sémantique des opérateurs feignants est clair. Il faut
juste la lire de la bonne façon.

Oui et dans certains il faut aussi prendre la precaution de la relire
au cas ou ...

Enfin, pour moi, ce n'est pas franchement un exemple particulier de
code illisible.

La encore j'ai un doute sur la comprehension de ce que j'appelle
"illisible".

On ne parle pas de lire des centaines de lignes en une seule passe.
Par contre, une trentaine ... mais bien sûr, si tous les cas où l'on

Quand je fais de la maintenance de code, c'est rare que je n'ai que 30
lignes de code a consulter. Et quand je dit rare je suis genereux.

aurait pu utiliser un || ou un && on a utilisé un double if, on voit
plus grand chose dans 30 lignes. Enfin, pour moi un code plus "long"

Ouais faut pas pousser non plus, je parle pas de remplacer tout les
operateurs logiques :)

n'est pas forcément plus lisible (en plus dans le cas du double if,
on se retrouve avec une hierarchie de "if" suffisament ambigue, pour
justement rendre les choses moins lisible.)

La par contre je te suis plus.

Maintenant, comme je l'ai dit, ça dépend de ce que tu utilises.
Typiquement, le while (--i) pour savoir ce qui se passe ... en une
seule passe ...

Pourtant ca saute aux yeux !!! ;)

Le truc, c'est que je ne suis pas sûr que des if imbriqués se soient
tellement plus lisible (en fait, personnellement, malgrès
l'indentation, une série de if imbriqués fait partie des trucs que
je considère comme dure à lire.) Mais vision personnelle est de
réduire le bruit pour rendre un code lisible autant que d'éviter les
expressions bourrées d'effets de bord, d'autant plus que dans le cas
qui nous interesse, il n'y a pas réellement d'effet de bord.

Bref tu l'auras ecrit comme ca :
if (!page_dir[j] && !malloc_make_chunks(j)) return 0;

Une chose est sure on est pas du tout d'accord :)))

mips

On Tue, 27 Apr 2004 17:34:58 +0200
Cyril Guibourg <plonk-o-matic@teaser.fr> wrote:

Marwan Burelle <burelle@lri.fr> writes:

Maitenant, j'aurais tendance à dire qu'il ne vaut mieux pas
toucher au C(ou à des langages du même genre) lorsque l'on a pas
un minimum de compréhension de ce qu'il se passe derrière.

Voilà, il faut y aller progressivement: code machine -> assembleur
-> C

Autant s'arreter a l'assembleur, le C n'est pas assez optimise.

Maintenant, hein, tout ça, ça sent le troll, malheureusement ...

mais non

Oui d'abord, remetons les choses en place. Un troll ca sent pas, ca
pue.

mips