Erreur du preprocesseur

In article <47ea0bc4$0$7687$426a34cc@news.free.fr>,
candide <c.candide@free.fr> wrote:

In article <47e98121$0$3604$426a34cc@news.free.fr>,
candide <c.candide@free.fr> wrote:

- les constantes (dommage que C n'ait pas emprunte a C++ en la matiere)
et les enums ?

A moitie pourries pour plein de raisons, entre autres parce qu'on ne sait pas
exactement a quel type elles correspondent.

Quoi ? les enum pourries ?

6.7.2.2:
Each enumerated type shall be compatible with char, a signed integer type
or an unsigned integer type. THE CHOICE OF TYPE IS IMPLEMENTATION DEFINED,
but shall be capable of representing the values of all the members of the
enumeration.

Note: An implementation may delay the choice of which integer type
until all enumeration constants have been seen.

Aucune autre precision sur la facon dont le compilo va choisir le type...
Tu as une enum, tu ne sais pas quel type entier lui correspond, ni meme
si c'est un type signe ou pas.

le préprocesseur pas loin de l'être ?

Un nombre important de corrections a faire lors de chaque update de gcc...

t'as un autre langage à me conseiller ?
Plein! ca depend de ce que tu veux faire... perl est mon choix cote langage

de developpement rapide.

C++ est une mauvaise réponse : la vie est courte ;)

T'es pas non plus oblige de TOUT apprendre du langage.
A mon avis, C++ est une bonne idee: oblige a typer les choses un peu
plus proprement, et possede rapidement nombre d'avantages, sans avoir
besoin de TOUT maitriser.

Rien que:
- le typage
- les constantes
- les entrees-sorties bien foutues
- la surcharge de fonction
- les namespace

ca suffit a changer un peu la vie par rapport a du C.

In article <47ea0bc4$0$7687$426a34cc@news.free.fr>,

Aucune autre precision sur la facon dont le compilo va choisir le type...
Tu as une enum, tu ne sais pas quel type entier lui correspond, ni meme
si c'est un type signe ou pas.

Oui mais est-ce si important pour l'usage qu'on en fait ? Bon, c'est
vrai que moi j'en suis resté à des usages basiques mais en regardant du
code pro, je crois pas que ce soit tellement différent. Pour moi
l'intérêt est l'apparence plus lisible du code et que par rapport à
l'usage de constantes symboliques, on dispose de variables de type enum
truc. Tu proposes quoi à la place des enum ? des constantes symboliques ?

t'as un autre langage à me conseiller ?
Plein! ca depend de ce que tu veux faire...

Bah, tu sais je suis un programmeur du dimanche ;) J'ai choisi de faire
du C
parce que je voulais implémenter des algorithmes de cryptographie ou de
théorie
des graphes ou traitant de maths en général. Et puis je me suis pris au
jeu du C.

C++ est une mauvaise réponse : la vie est courte ;)

T'es pas non plus oblige de TOUT apprendre du langage.
A mon avis, C++ est une bonne idee: oblige a typer les choses un peu

Je ne pense pas être assez programmeur pour ça et j'aime bien aller
assez loin dans l'apprentissage voire la maitrise donc, vue la
difficulté reconnue du C++, je ne pense pas m'y lancer. Si je dois
choisir un nouveau langage, ce sera java, d'après ce que j'ai lu, assez
facile à apprendre, très répandu, pas si lent que ça, et ayant de
nombreuses possibilités. Je ne comprends pas que ce langage ne soit pas
plus enseigné dans les universités françaises, on en a fini avec Pascal
mais on en est encore au C (et un peu de Caml mais de moins en moins),
c'est le cas chez moi et dès le premier semestre de la première année
(pour tous les étudiants maths/info/PC). Les étudiants d'info
n'apprennent un langage objet qu'en L3 (java chez nous).

On 2008-03-26, candide <c.candide@free.fr> wrote:

C++ est une mauvaise réponse : la vie est courte ;)

T'es pas non plus oblige de TOUT apprendre du langage.
A mon avis, C++ est une bonne idee: oblige a typer les choses un peu

Je ne pense pas être assez programmeur pour ça et j'aime bien aller
assez loin dans l'apprentissage voire la maitrise donc, vue la
difficulté reconnue du C++, je ne pense pas m'y lancer.

La difficulté du C++ est, AMHA, à la fois une réalité et
un faux problème.
C'est une réalité dans le sens où il y a énormément de
choses "modernes" en C++, c'est un langage en fort mouvement,
et tout le monde a du mal à suivre (les compilos, les
enseignants, les bouquins, et les programmeurs).
C'est un faux problème dans le sens ou on peut connaître
à peine les bases du langages et déjà profiter de pleins
d'avantage (à commencer par string, vector, et les iostream).

Si je dois
choisir un nouveau langage, ce sera java, d'après ce que j'ai lu, assez
facile à apprendre, très répandu, pas si lent que ça, et ayant de
nombreuses possibilités. Je ne comprends pas que ce langage ne soit pas
plus enseigné dans les universités françaises, on en a fini avec Pascal
mais on en est encore au C (et un peu de Caml mais de moins en moins),
c'est le cas chez moi et dès le premier semestre de la première année
(pour tous les étudiants maths/info/PC). Les étudiants d'info
n'apprennent un langage objet qu'en L3 (java chez nous).

La question est vaste, nombreux sont ceux qui se la pose.
Chez nous, nous avons d'une part considéré que C restait
incontournable. Se pose alors la question de savoir où
le mettre dans le cursus. 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 ?

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

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

La question est vaste, nombreux sont ceux qui se la pose.
Chez nous, nous avons d'une part considéré que C restait
incontournable. Se pose alors la question de savoir où
le mettre dans le cursus. 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...

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

Oui mais est-ce si important pour l'usage qu'on en fait ? Bon, c'est
vrai que moi j'en suis resté à des usages basiques mais en regardant du
code pro, je crois pas que ce soit tellement différent. Pour moi

Oui, le cote `signe ou pas', c'est extremement important et vicieux.

assez loin dans l'apprentissage voire la maitrise donc, vue la
difficulté reconnue du C++, je ne pense pas m'y lancer.

T'es desesperant comme mec. D'une part, tu joues les Saint Thomas sur a
peu pres tout ce qu'on raconte.

Et la, pour C++, tu te referes a des `on dit'.

Tout maitriser en C++, c'est dur, mais ca n'est pas indispensable du tout.

Si tu tombes sur le `Accelerated C++' de Koenig, jettes-y un oeil, tu
risques d'agreables surprises...

En news:47e97e4b$0$11987$426a74cc@news.free.fr,
candide <c.candide@free.fr> va escriure:

àmha, c'est parfaitement
voulu, car il est vain de vouloir écrire du code complètement
portable si tu joues avec cela :

Les ouvrages de C sont peu loquaces et surtout peu précis concernant
le fonctionnement du préprocesseur. Et je n'ai jamais qu'un argument
de non portabilité ait été avancé

Tu te plains que des ouvrages ne sont pas locaces sur un sujet, et tu
voudrais qu'en plus d'être discrets, ils justifient cette discretion ? C'est
trop demander...

(je viens encore de re-parcourir ce qu'en dit K&R : aucun argument
de cet ordre).

Je te rappelle que le K&R a été écrit en 1978, et révisé en 1989 ; nous
sommes en 2008 ; la situation a un peu changé.

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.

Je comprends pas : si les préprocesseurs sont conformes à la norme, il
ne devrait pas y avoir de différence.

...mais comme ils ne sont pas tous conformes...

Où alors, la norme serait-elle
ambiguë sur l'algorithme d'expansion de macro (puisque c'était ça le
problème initial).

Elle l'est un peu (dans certains cas très particuliers, genre DR017), mais
avant d'être ambiguë, elle est surtout compliquée ; donc les implémentations
sont souvent problématiques.

voici l'astuce :

#STR(x) VAL(x)
#VAL #x
/* blabla */ STR(__LINE__) /* blabla */

et voilà pourquoi, j'ai eu besoin de mieux comprendre comment
fonctionne l'expansion d'une macro à paramètre .

Pourquoi ? Tu peux aussi bien prendre la formule ci-dessus comme une recette
de cuisine ? C'est ce que font beaucoup de gens, et cela fonctionne très
bien...

Cela étant, j'ai vu que tu avais décortiqué ce cas-là, donc où est le
problème réel ?
Et oui, je vois une différence entre l'expansion de plus(plus(...)), et le
truc de Bill Plaugher avec le double appel de macro pour forcer l'expansion
: le premier est sujet à problème, pas le deuxième (entre autres raisons,
parce que ce truc est tellement utilisé que n'importe quelle implémentation
va l'avoir dans son jeu de tests de validation, donc c'est effectivement
portable).


Antoine

T'es desesperant comme mec. D'une part, tu joues les Saint Thomas sur a
peu pres tout ce qu'on raconte.

Chat échaudé : une fois que j'avais investi, disons un an, à apprendre
le C, difficile de faire marche arrière, l'investissement était trop
important. Et même après 2 ans et demi, je vois que je suis encore assez
loin de la maitrîse. Si je veux comprendre la logique du C++, je pense
que c'est assez long (sans compter que je vais devoir désapprendre le C).

Et la, pour C++, tu te referes a des `on dit'.

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").

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").

Tiens c'est marrant, j'ai lu aussi ce livre. Je dis ça car la maison
d'édition (H&K) est peu connue. J'adore les livres qu'ils font en
informatiques. Ils sont toujours très clairs.


François

François

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++ ;)

Tu te plains que des ouvrages ne sont pas locaces sur un sujet, et tu

Je ne m'en plains pas, je le déplore, nuance.

voudrais qu'en plus d'être discrets, ils justifient cette discretion ?

oui c'est bien ce que je voudrais

C'est
trop demander...

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


Quand je dis que les ouvrages sont assez peu loquaces concernant le
préprocesseur, disons que c'est la situation très majoritaire. Mais
Harbison & Steele s'étendent quand même (30 pages).


Il faudrait que je lise la Rationale sur cette question, je ne serais
pas étonné qu'elle soit très "éclairante".

Je te rappelle que le K&R a été écrit en 1978, et révisé en 1989 ; nous
sommes en 2008 ; la situation a un peu changé.

Certes mais là encore il faudrait qu'on sache une bonne fois pour tout
ce qu'il faut prendre et laisser dans le K&R. Sur ce forum et aussi sur
clc, et dans les bouquins, etc, on conseille K&R, c'est un package : à
prendre ou à laisser. Et finalement, on se rend compte que le livre
laisse à désirer sur de nombreux aspects ...

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

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

voici l'astuce :

#STR(x) VAL(x)
#VAL #x
/* blabla */ STR(__LINE__) /* blabla */

et voilà pourquoi, j'ai eu besoin de mieux comprendre comment
fonctionne l'expansion d'une macro à paramètre .

Pourquoi ? Tu peux aussi bien prendre la formule ci-dessus comme une recette
de cuisine ?

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

Cela étant, j'ai vu que tu avais décortiqué ce cas-là, donc où est le
problème réel ?

Il m'a fallu pas mal de lectures avant de parvenir à ce décorticage.
Même si au bout du compte, le processus semble élémentaire. Je n'ai
compris qu'en lisant et relisant la norme, quand même incroyable de
devoir en arriver là. Le gros bouquin de Delannoy dont on a dit beaucoup
de mal s'est montré relativement clair.

: le premier est sujet à problème, pas le deuxième (entre autres raisons,
parce que ce truc est tellement utilisé

Je ne connaissais pas. Mais puisque c'est si répandu, ça devrait dans
les livres (ce qui m'ennuie entre autres avec les livres de C, c'est
qu'ils ne sont pas le reflet de la _vraie_ programmation, qu'elle soit
correcte ou hérétique).