Erreur du preprocesseur

Comme il n'y avait pas de questions de toi depuis quelques jours, je me
demandais si tu avais abandonné le C ou si t'étais déjà passé au C++ ;)

:-)

Non, je n'ai pas abandonné, loin de là. Mais quand je ne suis plus
en vacances, *hélas* je ne peux lire que très très très ponctuellement.
Mais je garde toujours un oeil sur ce forum.

Au passage, ces histoires d'expansions de macros, ça parait toujours
simple au départ. Mais en fait, ça peut devenir assez compliqué. C'est
un peu comme du TeX qui est un langage basé essentiellement sur la
notion de macro. Je n'y connais pas grand chose, mais j'ai souvent
entendu dire que la programmation TeX était quelque chose extrêmement
difficile, notamment par rapport à ces histoires d'expansions ou de non
expansions de macro. En fait, le problème avec les macros, c'est qu'on a
un source mouvant.


François

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

Au passage, ces histoires d'expansions de macros, ça parait toujours
simple au départ. Mais en fait, ça peut devenir assez compliqué. C'est
un peu comme du TeX qui est un langage basé essentiellement sur la
notion de macro. Je n'y connais pas grand chose, mais j'ai souvent
entendu dire que la programmation TeX était quelque chose extrêmement
difficile, notamment par rapport à ces histoires d'expansions ou de non
expansions de macro.

En effet.
Disons que c'est un peu comme le C: si tu te contentes d'un
usage basique, c'est simple. Sinon, non.
Par contre, comme c'est le coeur de TeX, même si c'est compliqué,
il reste très peu de bug.

En fait, le problème avec les macros, c'est qu'on a
un source mouvant.

Notons aussi qu'il existe d'autres langages de macros. Le
plus célebre étant surement m4. Si on veut faire des choses
compliquée sur un code source, il vaut parfois mieux utiliser
d'autres outils, m4, awk, sed, perl.

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

Au passage, ces histoires d'expansions de macros, ça parait toujours
simple au départ. Mais en fait, ça peut devenir assez compliqué. C'est
un peu comme du TeX qui est un langage basé essentiellement sur la
notion de macro.

Tiens voilà bien quelque chose où j'accepte de ne rien maitriser : quand
j'ai un problème avec LaTeX, je me dis "bon, ben quel package va bien
pouvoir me faire ça ?" Et c'est vraiment rare que je n'obtienne pas la
réponse. Quant à TeX ... Tiens si on pouvait avoir les mêmes résultats
qu'autorise TeX mais en écrivant en C++, ça me motiverait peut-être à
apprendre ce dernier.

In article <47ea597c$0$5152$426a74cc@news.free.fr>,
candide <c.candide@free.fr> wrote:

Le "on" n'étant pas n'importe qui, j'ai passé de longues heures à
compulser les archives de fclc++ pour essayer de me faire une idée. Je
me fis aussi à ce que dit Thomas Pornin (en lequel j'ai une très grande
confiance) dans son petit bouquin "Comment choisir un langage de
programmation").

Thomas est un gentil garcon, mais qui a son propre point de vue sur le
monde... et c'est connu qu'il n'aime pas C++, et programme souvent `a
la dure'... ceci-dit, ces derniers temps, il est plutot passe a Java...

En news:47ea6aa6$0$20966$426a74cc@news.free.fr, candide va escriure:

C'est trop demander...

Non, c'est une question d'honnêteté intellectuelle.

Bon, je vais pousser plus loin le bouchon pour te montrer ce que je voulais
dire : tu achètes un livre qui parle de fromages, le livre est muet ou très
fugace sur le choix des vins pour accompagner les fromages, tu te plains de
cette locacité (ce qui est ton droit le plus strict), et ensuite tu accuses
l'auteur de ne pas être honnête intellectuellement...
Là je trouve que c'est bourré.

Sur ce forum et aussi sur clc, et dans les bouquins, etc, on
conseille K&R,

Oui.

c'est un package : à prendre ou à laisser.

Non. En tous cas, ce n'est pas ma position. Je pense que c'est un bon
ouvrage, mais ce n'est pas le seul, il ne couvre pas tout, et qui plus est
il est perfectible sur certains points.

Cela étant, d'autres lui sont tellement inférieurs que parfois, il faut être
un peu emphatique sur la qualité, c'est nécessaire pour garder un esprit
positif.
;-)

Et finalement, on se rend compte que le livre laisse à
désirer sur de nombreux aspects ...

Un problème qui arrive souvent lorsqu'on a des comportements manichéistes.

nous sommes en 2008 ; la situation a un peu changé.

Tu fais allusion aux fonctions inline et aux macros "variables" ?

En l'occurence, je faisais allusion à l'existence de la norme du langage C,
et à la portabilité des programmes écrits en C.

Certainement pas, mon but étant, dans un premier temps, moins de
programmer que de _comprendre_.

C'est peut-être bien le problème : le K&R et beaucoup d'autres ouvrages ont
été écrits pour apprendre à programmer...

Personnellement, pour comprendre le langage C, je m'intéresse plutôt à des
livres comme celui de C. Fraser et D. Hanson, /A Retargetable C Compiler:
Design and Implementation/, ISBN 0805316701,
http://www.cs.princeton.edu/software/lcc/. Mais bon, j'ai un passé de
développeur de compilateur et aussi de programmeur qui a appris à jongler
avec des ressources limitées, cela marque à la fin et ce n'est pas forcément
représentatif.

parce que ce truc est tellement utilisé

Je ne connaissais pas. Mais puisque c'est si répandu, ça devrait dans
les livres

Là je suis d'accord.
Il est logique que ce truc ne soit pas dans le K&R, puisque c'est une
conséquence de la formulation de la norme ANSI (et des spécifications
exactes de l'opérateur ##, ce qui a rendu ce genre d'opérations portables).
Par contre, dans des ouvrages d'une certaine envergure écrits depuis 10-15
ans, cela devrait figurer.
ÀMHA.


(Et de mémoire, je crois bien que c'est expliqué dans le livre sur lcc. Mais
je n'ai pas été vérifié.)


Antoine

In article <slrnfukj8g.l7j.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:

Quand à Java, c'est difficile (quoique...)
de faire java sans POO, et avant de faire de la POO, il
faut bien faire les bases de la programmation impérative.
Et avec quel langage ?

Avec java, bien sur.
Contrairement a ce que tu dis, il y a des tonnes de neuneus qui
arrivent tres bien a survivre et faire de la prog imperative a coup
de java, sans beneficier de la moindre once d'OO propre...

Un bon programmeur impératif est capable de faire de l'impératif
dans n'importe quel langage...

En news:47ea6aa6$0$20966$426a74cc@news.free.fr, candide va escriure:

C'est trop demander...
Non, c'est une question d'honnêteté intellectuelle.

Bon, je vais pousser plus loin le bouchon

Je ne sais pas pourquoi tu prends la chose tellement a coeur, la
malhonnêté intellectuelle ne te concernait pas.

pour te montrer ce que je voulais
dire : tu achètes un livre qui parle de fromages, le livre est muet ou très
fugace sur le choix des vins pour accompagner les fromages, tu te plains de
cette locacité (ce qui est ton droit le plus strict), et ensuite tu accuses
l'auteur de ne pas être honnête intellectuellement...

Ben ça dépend de ce qu'il a écrit ans sa préface.

En outre, même si je ne crois que telle était ton intention, on ne peut
pas considérer que la compilation soit le fromage et le préprocesseur le
vin, dans la norme, tu as : et fromage et pinard !

Mon terme de "malhonnêteté intellectuelle" est certainement trop fort et
inapproprié en effet, il serait plus convenable peut-être de parler de
"facilité intellectuelle". Mon propos va au-delà de la question du
traitement du préprocesseur. Quand tu vois par exemple un livre comme
"C, How to programm" de Deitel & Deitel, 5ème édition quand même ! qui
parle du C sur 1130 pages (!) et quand tu vois ce que tu appris lorsque
l'ouvrage est lu et toutes les questions _élémentaires_ (pour un
pratiquant quotidien) qui restent sans réponses ou à contour extrêmement
flou, et quand tu vois que ce phénomène se reproduit d'ouvrage en
ouvrage, tu te dis que les auteurs en question, mais je suppose que ça
va au-delà du langage C, se sont copiées entre eux, ne se sont pas
posées les bonnes questions et n'ont pas réfléchi au parcours qui joint
l'état de néophyte qui a peur du mot "compilateur" à celui qui va devoir
maîtriser le langage.

Quand j'ai commencé le C, je pensais que j'étais parti pour une
promenade de santé et qu'en 3 mois, je pouvais coder quelque chose de
substanciel tout en sachant ce que je faisais. Deux ans et demi après,
j'y suis encore. Si on dispose d'une doc suffisamment pensée et
élaborée, je reste persuadé que c'est possible.


Comme je l'avais dit sur ce forum il y a deux ans :

http://groups.google.fr/group/fr.comp.lang.c/msg/e09517c301553241?dmode=source

je crois que j'irai jusqu'au bout de ce travail de documentation.

Personnellement, pour comprendre le langage C, je m'intéresse plutôt à des
livres comme celui de C. Fraser et D. Hanson, /A Retargetable C Compiler:
Design and Implementation/, ISBN 0805316701,
http://www.cs.princeton.edu/software/lcc/.

OK, merci de la référence mais ça ne correspond pas au point de vue que
je veux garder, à savoir celui d'un _utilisateur_ et des _pratiquants_
du C et justement, je perdrais mon âme en quittant ce point de vue. Moi
je ne veux pas visiter les entrailles d'un compilateur, je n'ai ni le
goût ni le background pour ça. Pour moi, c'est une boîte noire, il est
_censé_ obéir à la norme ou éventuellement à sa propre doc. Comme je
l'ai déjà dit, le compilateur n'est pour moi qu'une interface, je ne
m'intéresse pas priori à son implémentation (naturellement j'ai bien
conscience que comprendre le fonctionnement interne d'un compilateur
voire son implémentation permet d'avoir une connaissance approfondie du
langage de même que quelqu'un qui connait les nombres complexes
comprendra mieux les équations polynomiales réelles mais je pense qu'il
n'est pas besoin d'en passer par là). Mon but est juste de parvenir à
écrire une documentation du C qui permette d'utiliser en un minimum de
temps le langage de manière aapprofondie
sans négliger les aspects de portabilité, de conception logicielle
propre au C, etc ni non plus les aspects périphériques du langage mais
incontournables et qui prennent beaucoup de temps dans l'apprentissage
(debugger, IDE, l'apprentissage d'une bibliothèque, etc).

Donc, ce que je proposerai, c'est un repas complet ;)

Mon but est juste de parvenir à
écrire une documentation du C qui permette d'utiliser en un minimum de
temps le langage de manière aapprofondie
sans négliger les aspects de portabilité, de conception logicielle
propre au C, etc ni non plus les aspects périphériques du langage mais
incontournables et qui prennent beaucoup de temps dans l'apprentissage
(debugger, IDE, l'apprentissage d'une bibliothèque, etc).

Donc, ce que je proposerai, c'est un repas complet ;)

Je jour où ça arrivera, n'oublie pas de faire une petite annonce, car
moi, ça m'intéresserait beaucoup, j'en suis sûr. ;-)


François

Je jour où ça arrivera, n'oublie pas de faire une petite annonce, car
moi, ça m'intéresserait beaucoup, j'en suis sûr. ;-)

Certainement mais c'est un travail assez méticuleux, dont les contours
ne sont pas encore bien définis et qui prendra donc du temps (déjà tout
le document sera saisi en xml et ... ma DTD n'est pas encore imaginée)
et d'ici là, je suppose que tu connaitras le C.

Tes avis de personne qui découvre le C seront pour moi très utiles même
si de mon côté j'ai pris soin d'annoter toutes mes lectures depuis le
départ et de tenir un journal.

De toute façon, je confronterai aux enseignants et praticiens du C ici
présents mes premiers essais. Mais le moment n'est vraiment pas encore
venu, je continue à approfondir mon C en codant et en lisant Plauger.

Le Tue, 25 Mar 2008 12:28:52 +0100, Antoine Leca <root@localhost.invalid>
a écrit:

En news:47e26470$0$20187$426a74cc@news.free.fr, candide va escriure:

Je trouve que l'algorithme de preprocess et en particulier d'expansion
de macros n'est pas clairement expliqué en général.

Par qui ? par les ouvrages d'enseignement du C : àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement portable
si tu
joues avec cela : ce domaine a mis du temps à mûrir, donc les
compilateurs
ont mis beaucoup de temps à se stabiliser, donc si tu joues trop sur les
bords tu vas trouver des cas où les compilateurs diffèrent, autrement
dit le
code n'est pas portable. Comme le gain réel est faible ou nul (car le
code
est difficile à comprendre pour un humain), ce n'est pas enseigné.

Qu'en pensez-vous ?

D'abord et surtout que le résultat est le même !

Ensuite que les principaux préprocesseurs conformes semblent à première
vue
pencher pour l'interprétation de MM. Harbison & Steele, mais je ne suis
pas
assez calé en préprocesseur pour être capable d'expliquer clairement
pourquoi. Ce qui me paraît clair, c'est que l'interprétation précise
demande
l'intervention de spécialistes, donc tout code qui essaye de jouer au
plus
fin est susceptible de rencontrer des bogues dans les implémentations, et
par conséquent un bon programmeur devrait éviter de jouer à cela ; ce qui
rejoint l'analyse ci-dessus.


Antoine

Je précise, avant de donner un avis, que j'ai dirigé le développement d'un

compilateur C (avant que la norme ANSI C existe, elle était à l'état de
draft à l'époque) et que je suis spécialiste de la compilation (que j'ai
enseignée).

Le principe de substitution à mettre en oeuvre dans le préprocesseur C
devrait être celui du mécanisme de substitution du lambda-calcul et la
"beta-reduction" (cf.
http://www.techno-science.net/?onglet=glossaire&definitionb14).
Dans ce cas, c'est l'interprétation de MM. Harbison et Steele qui est la
bonne.
Hélas, nombre de développeurs de compilateurs ne comprennent pas le
lambda-calcul et son mécanisme de réduction.
Dans le cas cité par Candide, on arrive au même résultat mais ce n'est pas
toujours le cas...

Par ailleurs, concernant les bouquins sur le C, celui de MM. Harbison et
Steele était un des meilleurs, sinon le meilleur, à l'époque.
Celui de P. Drix est bien aussi et montre comment on peut programmer
"proprement" en C.
Le bouquin de K&R est à déconseillé pour l'apprentissage du C et même pour
l'enseignement de la programmation car nombre d'exemples relèvent plus du
"hacking" au sens de "développeur fou" que de la qualité de programmation
à fournir dans un contexte industriel.

Je conseille, par ailleurs, à Candide, de se pencher sur C++ ou Java et de
ne pas perdre son temps sur le langage C qui est un des langages les plus
"pourri" que je connaisse car sa sémantique n'est pas parfaitement
définies pour toutes les constructions syntaxiques valides (ceci explique
les différences d'interprétation des différents compilateurs).
Par ailleurs C n'est pas un langage à fort typage, ce qui, de fait, nuit à
la fiabilité des programmes écrits dans ce langage.

Je suis également spécialiste des applications militaires pour les
systèmes de commandement et les telecoms. Aujourd'hui, tout cela est écrit
en C++ ou en Java. Il n'y a plus de C...

Pour l'apprentissage de la programmation, je persiste à penser que ADA 83
(pas l'ADA objet de 95) est un très bon langage. Mon expérience montre que
des étudiants ayant commencé par le langage ADA codent beaucoup plus
proprement en C que tous les autres.

Aujourd'hui ou, qu'on le veuille ou non, l'approche objet prédomine, le
meilleur langage pour apprendre la programmation est Java (du moins un
sous-ensemble). Ceci permet aux étudiants d'être directement opérationnels
dans l'industrie (parce que s'ils doivent faire du C#, par exemple, ou du
C++, l'écart n'est pas très grand avec Java. Cependant, vouloir maîtriser
tous les aspects de C++, requiert une bonne dose de patience et plusieurs
année de pratique de ce langage.

PS : ma famille de langages favorite est celle des langages fonctionnels
"à la CAML" (mais objet, donc OCaml : cf.
http://caml.inria.fr/ocaml/index.fr.html)