Chercher un livre sur le C avec certains critères.

On 2008-03-10, Francois <mathsattacks@free.fr> wrote:

Ceci dit, je suis convaincu que pour bien programmer portable,
il est utile de connaître les origines des défauts de portabilité.

J'y connais pas des masses, mais j'approuve. D'une manière générale, le
"non dit" dans le but d'être irréprochable dans son discours est, selon
moins, une erreur pédagogique. Je trouve plus pédagogique de dire et de
montrer.

Le problème, c'est montrer *quoi* ?
Si on donne *une* illustration, elle est souvent confondue par
l'apprenant comme une définition.

Le fait est que la plupart des "non dit" du C sont là pour masquer
une diversité d'architecture processeurs très vaste.

Si on part de l'idée naïve qu'un pointeur est un entier représentant
l'adresse d'un char (représentation courante), alors, toutes les
subtilités de conversions entre pointeurs semblent là juste pour
compliquer les choses.
Les règles "à la con" sur les pointeurs sont là pour masquer
les autres implantations...

Dans la discussion que j'ai mise en lien dans premier message de ce fil,
un certain -ed- me disait "non, ça, c'est pas toujours vrai. Dans ce
cas là ...". Il pouvait dire ça car, lui, il a probablement du voir et
constater (parfois à ces dépens) plein de problèmes du genre. Tant qu'on
a pas vu...

Tant qu'on a pas vu "quoi" ?
On ne peut lister sous chaque "limitation" du C toutes les archis
qui iraient contre le "sens commun", sens commun qui peut varier d'un
étudiant à l'autre en plus.

Autre exemple (désolé, j'en reviens au maths).

a) Définition avec non dit irréprochable
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f

b) Définition sans non dit, irréprochable aussi
UNE primitive de f sur I est une fonction F dérivable sur I tq F'=f
Attention, on dit UNE, car si on en trouve une, alors on en déduit plein
d'autres en additionnant une constante. exple ...

Sauf que les théories mathématiques sont généralement cohérentes,
et qu'elles se tapent de savoir si en 1983, un processeur populaire
a eut tel adressage bizare.

Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre
'static' devant les fonctions qui sont dans le .c et pas dans le
.h ? Le compilo peut pas s'en appercevoir tout seul ?"
Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...

En math, on manipule en général peut de concepts, mais ils sont
compliqués. En info, c'est l'inverse.

Tout ça pour dire juste ceci :

Le problème, c'est que, lorsqu'on évite le non-dit, c'est plus difficile
(plus fatiguant) d'être irréprochable.

Plus fatiguant aussi pour le lecteur.
Tient, pourquoi on pourrait pas faire
i= ++i
Si on a pas de notions d'exécutions paralleles dans les processeurs,
oui, on peut se dire que c'est ridicule comme restriction. En même
temps, vu comment nos étudiants on déjà du mal avec les processeurs
séquenciel sans pipe-line, c'est difficile de s'appuyer sur le contre
exemple.

Dans ma formation d'informaticien, il y avait des cours
d'algorithmique, d'architecture des ordis, de compilation,
de système d'exploitation, et tout cela me sert à "lire entre
les lignes" de la norme C, et c'est très insuffisant, ce
qui m'ammène ici pour discuter avec plus savant que moi.

Et toi, tu voudrais un bouquin avec tout ?

Comme le disais je ne sais plus qui ici, l'informatique est
le seul métier où l'on ose vendre un bouquin de 120p et prétendre
faire un professionel avec ça...
Pour faire un informaticien débutant correct, je ne sais pas faire
en mois d'un an de formation, soit l'équivalent d'une vingtaine
de bouquins au minimum. Et encore, faut des gens motivés.

Pour moi, la pédagogie que
j'aime, c'est celle de l'explicite (pas de non dit). Où le lecteur ne
doit pas jouer aux devinettes. Le tuto dont nous avons parlé avant
essaye de faire cela.

Et il y arrive ?

Bon d'accord, hélas, il y a des erreurs.

Ah, oui...

Avec K&R,
quant à lui, j'ai un peu l'impression qu'il faut parfois jouer aux
devinettes (cf : quelques messages avant à propos des tableau). C'est
une référence. Ca doit bien quand tu connais déjà très bien le C et que
dans ta tête les choses sont déjà bien en place.

Je ne défend pas becs et ongles le K&R. Ceci dit, je suis bien en
peine pour conseiller autre chose.

Je passe à autre chose.

a) Pour nos histoire de formalisme (lvalue etc.). Finalement, n'est-ce
pas un peu vain. Cela apporte-t-il quelque chose au programmeur ?

Oui et non.
Franchement, je ne suis toujours pas au clair sur la notion de lvalue,
et ça ne m'empèche pas d'enseigner un sous-ensemble utile du C.
Quand même, bien souvent, le code "raisonnable" d'écrit sans avoir
besoin de ces détails.
Mais parfois...

J'ai vraiment l'impression que ce formalisme de toute façon n'est pas
clairement et officiellement défini (je me trompe peut-être ?)

Ben, il existe une norme officile, si (plusieurs même).

et j'ai
l'impression aussi qu'au final, ce qui compte, c'est d'avoir sa propre
terminologie (en évitant quand même de faire un truc marginal) et
qu'elle soit cohérente. Non ?

Ben moi, il me semble que l'enjeux majeur de l'informatique en 2008,
c'est la communication dans le développement, que ce soit avec les non
développeurs, qu'entre développeurs, communication synchrone et
asynchrone (genre, reprendre un code 3 ans après que quelqu'un d'autre
l'ai écrit, et ait quitté la boite il y a déjà 2 ans).
Donc, une terminologie partagée me semble au contraire fondamentale.

b) Pouvez-vous me dire où je peux me procurer les normes C ?

Les normes officielles chez l'ISO ou l'ANSI. Whiley en a une version
papier. Il existe des drafts librement téléchargeable.
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n869/

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Je trouve qu'il ne parle pas assez de la
"représentation des valeurs en C", ensuite il parle des 3 différentes
représentations classiques des entiers signés mais je suis resté sur ma
faim (il en parle là mais il n'en parle plus après donc c'est un peu
académique) puis il parle des opérations sur les bits d'entiers non
signés, très classique.

Que dire de plus ?

Ça je te le dirai une fois que j'aurai un peu plus roulé ma bosse.

Et c'est d'ailleurs peut-être moins une question de "qu'est-ce qu'il
faut dire" mais plutôt "comment le dire".

Comme j'avais déjà dit ici : c'est comme une histoire drôle dont tu
comprends tous les mots et toutes les phrases et qui ne te fait pas rire.

En fait, pour arriver à comprendre et sentir, il faudrait que je me
trouve concrètement en situation de porter des programmes que j'aurais
écrits sur une architecture sur une autre. Justement la chose que je
voulais éviter (un ouvrage bien écrit est justement censé te faire
l'économie de l'expérience).

Et toi, tu voudrais un bouquin avec tout ?

Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un
matheux. En maths, quand on présente un chapitre particulier, ce qui est
présenté l'est en principe de manière "complète".

Je m'explique. Quand on apprend un cours sur les espaces vectoriels par
exemple, on part de définitions à partir desquelles tout est construit
au fur et à mesure. Donc en principe, à un instant donné, tout ce qui a
été vu ne souffre d'aucune ambiguïté, d'aucune zone d'ombre, et se
présente comme quelque d'achevé complètement (et je trouve ça très
agréable, c'est pour ça que j'aime bien les maths). Après, on peut
toujours continuer à aller plus loin dans telle ou telle théorie (et
s'apercevoir que finalement on n'en verra jamais le bout bien sûr), mais
ce qui est "derrière soi" à un côté achevé, ça c'est cool.

J'ai sûrement tendance à vouloir reproduire ce schéma dans d'autre
activité, ce qui est bien sûr une chimère. Bon en fait, même en maths
c'est quand même une chimère, mais vachement moins que dans d'autres
activités (mais là je m'égare).

J'espère avoir été clair ?
Bon, et puis désolé si j'ai un peu fait le p'tit péteux qui débarque la
fleur au fusil. Je pense qu'il faut que jeunesse se passe. :-))

Ceci étant, j'aurais bien voulu un livre sur le C avec un chouille
d'architecture, parce que j'avais (peut-être à tort) l'impression que ça
m'aurait plu, je ferai sans.

J'ai eu plein de réponses et la discussion m'a fichtrement intéressée et
amusée. C'est vrai, pourquoi diable un domaine comme l'informatique
déchaîne-t-il toujours les passions ? (ce n'est pas péjoratif dans ma
bouche)

Très grand MERCI à tous.

Bref, je vais continuer à lire le K&R (j'ai déjà des questions dans ma
besace ... c'est pour bientôt sur le fclc :-) ). Et puis après on
verra... c'est pour bientôt sur le fclc :-) ). Et puis après on verra...


François

In article <fr481f$ju8$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Si on part de l'idée naïve qu'un pointeur est un entier représentant
l'adresse d'un char (représentation courante), alors, toutes les
subtilités de conversions entre pointeurs semblent là juste pour
compliquer les choses.

Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement
sur les trucs plus gros, ou des octets de bourrage... ou alors, les
vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et
size_t ne font qu'ajouter a l'immonde bordel ambient.

Je ne vois plus trop l'interet de mentionner les autres cas bizarres.
Ah si, il y a les pointeurs de fonction, quand meme, les ABI ppc ayant
des choses rigolotes sur les passages de parametres.

Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.

Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre
'static' devant les fonctions qui sont dans le .c et pas dans le
.h ? Le compilo peut pas s'en appercevoir tout seul ?"
Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...

Non, toujours pas en 2008... Comment tu fais la difference entre les
fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles
qui n'y sont pas parce qu'on les a oubliees ?

Une ceinture et des bretelles... pour une fois qu'on a un mecanisme
un peu redondant pour etre a peu pres sur de ce qu'on veut, on va
pas s'en priver.

(a cote de ca, je bosse sur un projet ou les fonctions locales du noyau
ne sont PAS annotees avec static, parce que sinon c'est trop la zone a
debugguer...)

--{ Francois a plopé ceci: }--

Et toi, tu voudrais un bouquin avec tout ?

Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un
matheux.

Dans ce cas, il y a peut-être un bouquin qui te plairait, c'est

du C assez pointu et le titre du livre parle de lui-même:
"Programs and data structures in C" de Leendert Ammeraal,
(éditeur Wiley) avec des vrais trucs concrets dedans.

Ce monsieur a aussi écrit des trucs sur le graphisme et la 3d,
avec du code réel dedans. J'aime bien.

Ceci étant, j'aurais bien voulu un livre sur le C avec un chouille
d'architecture, parce que j'avais (peut-être à tort) l'impression que ça
m'aurait plu, je ferai sans.

Et pour ça, il faut peut-être regarder "Operating Systems" d'ast
(éditeur Prentice Hall) qui est en fait un énorme commentaire sur
le code source de Minix, donc des passages très <architecture>.

Bref, je vais continuer à lire le K&R

Sage décision.

--
Pourtant, sur Google, 80 000 occurrences de var/lib/dpkg/info contre
18 000 occurrences de var/log/packages.
--{ Sam, statisticien dans fcol.debats }--

--{ candide a plopé ceci: }--

En fait, pour arriver à comprendre et sentir, il faudrait que je me
trouve concrètement en situation de porter des programmes que j'aurais
écrits sur une architecture sur une autre. Justement la chose que je
voulais éviter

C'est une chose que l'on ne peut jamais éviter tout à fait.
Par exemple quand tu travailles sur des fichiers binaires
comme les fichiers image (bpm, tga, pcx, tiff...) sur plusieurs
architectures différentes. Et pour aller dans le concret, une
vieille Sun genre ss20, ça se trouve à pas cher[1], et ça rend
modeste sur la "portabilité" du code que tu écris :)

[1] mais p'taing comment ça fait du bruit !

--
Les hackers sont nos amis. Des amis bizarres aux goûts et aux horaires
curieux, mais qui ne feraient pas de mal à une mouche, même pas pour
savoir comment ça marche dedans ; pourquoi découper un insecte quand
on peut poser la question sur Slashdot ?.

Francois <mathsattacks@free.fr> writes:

Et toi, tu voudrais un bouquin avec tout ?

Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un
matheux. En maths, quand on présente un chapitre particulier, ce qui est
présenté l'est en principe de manière "complète".

On ne flanque pas le premier volume du tome un des oeuvres de Bourbaki au
CP. Je le sais, mon aine est au CP. Tu oublies qu'en math tu as deja fait
3 ou 4 iterations sur ces concepts en approndissant a chaque fois.

A+

--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org

On 2008-03-10, candide <c-candide@wanadoo.fr> wrote:

Je trouve qu'il ne parle pas assez de la
"représentation des valeurs en C", ensuite il parle des 3 différentes
représentations classiques des entiers signés mais je suis resté sur ma
faim (il en parle là mais il n'en parle plus après donc c'est un peu
académique) puis il parle des opérations sur les bits d'entiers non
signés, très classique.

Que dire de plus ?

Ça je te le dirai une fois que j'aurai un peu plus roulé ma bosse.

Et c'est d'ailleurs peut-être moins une question de "qu'est-ce qu'il
faut dire" mais plutôt "comment le dire".

Comme j'avais déjà dit ici : c'est comme une histoire drôle dont tu
comprends tous les mots et toutes les phrases et qui ne te fait pas rire.

Ce forum est un bon lieu pour demander les éclaircissements.

En fait, pour arriver à comprendre et sentir, il faudrait que je me
trouve concrètement en situation de porter des programmes que j'aurais
écrits sur une architecture sur une autre. Justement la chose que je
voulais éviter (un ouvrage bien écrit est justement censé te faire
l'économie de l'expérience).

Bof... Je n'ai pas croisé beaucoup d'archis dans ma vie (rien que
du Sun/Solaris et de l'x86/Win*-Linux), et je suis quand même
pas mal sensibilisé au problème.

Je crois que c'est surtout le temps qui fait, le fait de ruminer,
de se poser des questions, et de discuter avec des pros. Ce forum est
dans ce sens assez unique.

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

On 2008-03-10, Marc Espie <espie@lain.home> wrote:

In article <fr481f$ju8$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Si on part de l'idée naïve qu'un pointeur est un entier représentant
l'adresse d'un char (représentation courante), alors, toutes les
subtilités de conversions entre pointeurs semblent là juste pour
compliquer les choses.

Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement
sur les trucs plus gros, ou des octets de bourrage... ou alors, les
vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et
size_t ne font qu'ajouter a l'immonde bordel ambient.

C'est vrai que j'avais zappé les alignements tellement ça me
paraît "naturel" maintenant ;-) Je pensais à des trucs comme
le "one past end".

Et puis bon, je suis trop nul en archi pour savoir quels sont
les problèmes de "ces temps ci".
Je pensais aussi aux adressages base+index, qui fait que tu
peux mettre l'un ou les deux dans un pointeur, et qu'en plus,
l'égalité base+index n'est pas l'égalité binaire.

Je ne vois plus trop l'interet de mentionner les autres cas bizarres.
Ah si, il y a les pointeurs de fonction, quand meme, les ABI ppc ayant
des choses rigolotes sur les passages de parametres.

En effet.

Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.

Peux-tu me rappeller ce que tu appelles "aliasing" ?

Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre
'static' devant les fonctions qui sont dans le .c et pas dans le
.h ? Le compilo peut pas s'en appercevoir tout seul ?"
Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...

Non, toujours pas en 2008... Comment tu fais la difference entre les
fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles
qui n'y sont pas parce qu'on les a oubliees ?

Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise
ailleurs, ce sera une utilisation sans prototype, et ça risque de pas
bien marcher.
Donc, ça ne va casser que du mauvais code.

(a cote de ca, je bosse sur un projet ou les fonctions locales du noyau
ne sont PAS annotees avec static, parce que sinon c'est trop la zone a
debugguer...)

Comme je dis à mes étudiants: je donne pleins de règles simples,
que vous serez ammenés à contourner parfois. Mais ce jour là, vous
saurez *pourquoi* j'ai donné cette règle et pourquoi, dans ce cas
là, il ne faut pas l'appliquer.

Tient, on commence l'année en disant qu'il ne faut pas de variable
globale, et à la fin de l'année, quand on faut un mini purify,
qui surcharge malloc/calloc/free, ben, on en utilise...

Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)

Le 11-03-2008, à propos de
Re: Chercher un livre sur le C avec certains critères.,
Thierry B. écrivait dans fr.comp.lang.c :

--{ candide a plopé ceci: }--

En fait, pour arriver à comprendre et sentir, il faudrait que je me
trouve concrètement en situation de porter des programmes que j'aurais
écrits sur une architecture sur une autre. Justement la chose que je
voulais éviter

C'est une chose que l'on ne peut jamais éviter tout à fait.
Par exemple quand tu travailles sur des fichiers binaires
comme les fichiers image (bpm, tga, pcx, tiff...) sur plusieurs
architectures différentes. Et pour aller dans le concret, une
vieille Sun genre ss20, ça se trouve à pas cher[1], et ça rend
modeste sur la "portabilité" du code que tu écris :)

[1] mais p'taing comment ça fait du bruit !

Faux. Cela dépend essentiellement du disque dur qu'il y a à
l'intérieur. J'ai une pile de SS20 juste derrière mon dos :
- dual SM71 qui fait un barouf d'enfer (deux disques Seagate de 36
Go) et qui me sert à débugguer les noyaux Linux 2.6 en sparc32/SMP
(et maintenant, ça marche !), mais il faut recompiler tous les
paquets debian en sparc v8 only :-(
- dual RT626 avec un seul disque Fujitsu 73 Go qui est _très_
silencieuse, enfin largement plus que mon U2 qui ne fait pas
beaucoup de bruit. C'est une machine de calcul sous NetBSD
- quad RT626 avec deux disques Fujitsu de 300 Go

Un truc bizarre, d'ailleurs... Les RT626 semblent moins chauffer
avec NetBSD qu'avec Linux...

Quant à la portabilité, je goretscribouille du C et du Fortran
(tTh, pas de remarque !) et les seuls problèmes de portabilité vers
sparc que je n'ai jamais eu, c'est en fait des problèmes de
portabilité plus liés à NetBSD et à l'absence de signaux RT qu'à la
taille des mots ou aux problèmes grand/petit boutistes.

JKB, épavologue

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.