Pourquoi du C pur ?

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | Mon principe est qu'en lisant une fois une interface (un
| > header) on devrait
| > Mauvais principe, changer de principe.
|
| Principe venant de Kernighan et il ne parlait pas d'un language en particulier :-)

principe énoncé il y a bientôt 30 ans et la manière de concevoir les
programmes a beaucoup changé depuis. Le principe doit donc aussi changer.

| > Les gens devraient pas lire les en-têtes, mais les spécifications et
| > les documentations.
|
| Qui sont presque toujours obsolete ou inconsistante?

elles sont toujours obsolètes et inconsistantes par voie de
conséquence. Si les gens communiquaient par les interfaces et la
documentation au lieu de regarder les détails d'implémentation, les
spécifications et les documentations resteront à jour et seront
cohérentes. De fait, pour les projets raisonablement bien gérés sur
lesquels j'ai eu à travailler, il n'y a pas eu ce problème
d'incohérence car le protocole de commit incluait la documentation et le
review de la documentation des changements.

| C'est pas toi qui disait "the source is the documentation?"

oui c'est moi et je l'ai affirmé dans un contexte précis ; et dans le
contexte en question, je le maintiens encore.

[...]

| > | o on controle (presque) tout, ce n'est qu'une (fausse)
| > impression. De fait, on contrôle *moins* en C
| > qu'en C++. Pense typage, portée et abstraction. Ce sont des notions
|
| Je parlais de l'ABI, stable, connue, peu-evoluee (comme le C) et sans
| surprise a part qque trucs exotiques genre les signaux ou setjmp.

le typage fait partie de l'ABI.

[...]

| > | o il est plus simple de resoudre des problemes "non-standard" en C
| > | qu'en C++. Il suffit de voir le niveau plutot basique des
| > | questions sur fclc par rapport aux questions sur fclc++. Cela
| > | montre clairement que le C++ est plus difficile a maitriser et
| > | qu'on devient plus rapidement "autonome" en C. Cela compte |
| > beaucoup quand l'equipe de development change souvent.
| > Si l'on doit prendre le « niveau basique » des questions comme
| > critère, alors la conclusion seraint plutôt qu'on ne fait rien
| > d'intéressant en C, ou que les gens qui l'utilise sont encore en
| > petites culottes et ne sont pas encore arrivés à maturité.
| > Mais, ce n'est pas le cas. De fait, le « niveau basique » des questions
| > ne donne pas une idée de la complexité requise pour résoudre un
| > problème en utilisant le C. Je dirais plutôt que cela en dit plus long
| > sur le niveau des gens qui fréquentent le groupe ou qui y posent des
| > questions. En comparaison, je te demanderais de regarder le niveau des
| > questions sur comp.std.c ou comp.lang.c.moderated par exemple.
|
| Entierement d'accord. Mais plus de la moitie des questions postees sur
| ces newsgroup pourraient l'etre sur leur pendant C++ sans etre HS.

mais elles ne le sont pas ; cela tendrait à supporter l'idée de niveau
des gens qui posent les questions ;-)

| De
| fait, les questions sur le C++ mais ayant une nature C ne seront pas
| posees sur un NG C++ alors qu'elle pourrait l'etre pour avoir une
| reponse plus complete.

Itoo.


| Par exemple une question comme "When do
| pointers match" aura une reponse compliquee en C et encore plus
| compliquee en C++.

Je prédis que la réponse sera moins compliquée en C++ ;-)

-- Gaby

Gabriel Dos Reis wrote:

| C'est un groupe sur le C :-)

et alors ?

Et alors sur fclc je suis de mauvaise foi sur le C++ et sur fclc++ je de
mauvaise foi sur le C. J'aime bien les deux et j'aime bien etre de mauvaise foi :-)

| > de 1999 est sans doute nettement moins implémentée que la norme ISO C++98.
|
| Certes, mais l'effort a fournir pour que C99 soit supporte est bien
| moindre que pour C++98.

qu'est-ce que tu en sais ?

Pretendre le contraire serait pour l'occasion de la vraie mauvaise foi. Sans
ironie, qu'est ce qui serait une avancee majeure dans C99 et qui demanderait
tant de travail par rapport a C89 (ou C95) selon toi? Mis a part _Bool, long
long, _Complex et les varlen array (en general deja tous supportes en 1999 avec
une semantique proche) et la foultitude de types, macros et autres fonctions a
ajoutees dans la libc et qui demande surtout du temps et de la main d'oeuvre?
Par contre il y avait enormement a faire entre le C++ existant au moment de la
sortie de C++98 et le C++ qu'elle specifie.

| Cela ne veut pas dire que C++98 ne sera pas supportee avant C99.

je prédis que C++98 serait bien mieux supporté avant C99.

Pas de contradiction avec ce que je dis.

| Mais disons que pour que C99 soit supportee, cela
| demande une volonte de la part du fabiquant du compilateur et rien
| d'autre, en particulier l'ABI ne change pas (a ma connaissance).

la norme C (et aussi C++) ne spécifie pas une ABI. Ce sont deux choses
complètement orthogonales. L'ABI sur Itanium a bien changé par rapport
à x86, en ce qui concerne le C90.

Tu me parles de compatibilite d'architectures alors que je parle de
compatibilite de compilateurs pour une archi fixee. La premiere est forcement
plus difficile a achever.

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Gabriel Dos Reis wrote:

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | Mon principe est qu'en lisant une fois une interface (un
| > header) on devrait
| > Mauvais principe, changer de principe.
|
| Principe venant de Kernighan et il ne parlait pas d'un language en particulier :-)

principe énoncé il y a bientôt 30 ans et la manière de concevoir les
programmes a beaucoup changé depuis. Le principe doit donc aussi changer.

The Practice of Programming, 1999, ou on trouve entre autre du C++ et du Java et
des recommandations aussi valable pour la POO. Certe, j'adere pas a tout mais
ses "collected rules" sont une bonne base.

Je prédis que la réponse sera moins compliquée en C++ ;-)

Les points de vue et les experiences sont faits pour etre partages :-)

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > | C'est un groupe sur le C :-)
| > et alors ?
|
| Et alors sur fclc je suis de mauvaise foi sur le C++ et sur fclc++ je
| de mauvaise foi sur le C. J'aime bien les deux et j'aime bien etre de
| mauvaise foi :-)

En gros, tu n'es jamais de bonne foi. C'est entendu.

|
| > | > de 1999 est sans doute nettement moins implémentée que la norme
| > ISO C++98.
| > | | Certes, mais l'effort a fournir pour que C99 soit supporte est
| > bien
| > | moindre que pour C++98.
| >
| > qu'est-ce que tu en sais ?
|
| Pretendre le contraire serait pour l'occasion de la vraie mauvaise
| foi.

Pas du tout. As-tu implémenté l'une ou les deux spécifications ?

| Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| Mis a part _Bool, long long, _Complex et les varlen array (en general
| deja tous supportes en 1999 avec une semantique proche) et la
| foultitude de types, macros et autres fonctions a ajoutees dans la
| libc et qui demande surtout du temps et de la main d'oeuvre? Par
| contre il y avait enormement a faire entre le C++ existant au moment
| de la sortie de C++98 et le C++ qu'elle specifie.

À part l'arrogance des assertions, je remarque surtout une ignorance
complète des difficultés que soulèvent la nouvelle définition de C.
Les tableaux à taille variable (VLA) posent plus de problèmes que tu
ne sembles le croire. La nouvelle sémantique des opérations flottantes
est au moins de deux ordres de magnitude difficiles à supporter qu'un
pendant en C++ avec une volution bibliothèque. C'est encore plus
difficile qu'il faut modifier profondément l'architecture de nombre de
compilateurs majeurs existants. Comment implémentes-tu les
type-generic macros?
Il est facile de dire que l'implémentation des nouvelles fonctions de
la bibliothèque ne nécessite que de la main de d'oeuvre et du temps.
Mais la pratique est toute autre. Il ne suffit pas seulement d'avoir
de la main d'oeuvre et du temps. Et de fait, la main d'oeuvre et du
temps sont à comptabiliser dans « effort ». En attandant et les gens
de C99 aient « le temps et la main d'oeuvre » , l'implémentation de
C++98 progresse et est presque terminée, et c'est ce qui compte .

| > | Cela ne veut pas dire que C++98 ne sera pas supportee avant C99.
| > je prédis que C++98 serait bien mieux supporté avant C99.
|
| Pas de contradiction avec ce que je dis.

non ton affirmation n'exclut pas le cas contraire non plus. La plus
est plus décisive. C'est la différence.

| > | Mais disons que pour que C99 soit supportee, cela
| > | demande une volonte de la part du fabiquant du compilateur et rien
| > | d'autre, en particulier l'ABI ne change pas (a ma
| > connaissance). la norme C (et aussi C++) ne spécifie pas une ABI. Ce
| > sont deux choses
| > complètement orthogonales. L'ABI sur Itanium a bien changé par rapport
| > à x86, en ce qui concerne le C90.
|
| Tu me parles de compatibilite d'architectures alors que je parle de
| compatibilite de compilateurs pour une archi fixee.

Je te parle d'ABI puisque c'est sur ça que tu te fixes.

-- Gaby

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | Gabriel Dos Reis wrote:
| > | > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | > | Mon principe est qu'en lisant une fois une interface (un
| > | > header) on devrait
| > | > Mauvais principe, changer de principe.
| > | | Principe venant de Kernighan et il ne parlait pas d'un language
| > en particulier :-)
| > principe énoncé il y a bientôt 30 ans et la manière de concevoir les
| > programmes a beaucoup changé depuis. Le principe doit donc aussi changer.
|
| The Practice of Programming, 1999,

si tu regardes bien, c'est un rechauffé de quelque chose qu'il a
publié dans les années 1970 avec Plauger. À l'époque, cela portait
sur du Pascal.

-- Gaby

Gabriel Dos Reis wrote:

| > | > de 1999 est sans doute nettement moins implémentée que la norme
| > ISO C++98.
| > | | Certes, mais l'effort a fournir pour que C99 soit supporte est
| > bien
| > | moindre que pour C++98.
| >
| > qu'est-ce que tu en sais ?
|
| Pretendre le contraire serait pour l'occasion de la vraie mauvaise
| foi.

Pas du tout. As-tu implémenté l'une ou les deux spécifications ?

Non. Toi non plus. En dehors d'etre provocatrice, cette question est inutile et
je ne te suivrais pas dans ce jeux la. Peu de gens (s'il en existe) ont
implemente eux-meme l'une ou l'autre de ses specifications (ou une version
anterieure) dans leur totalite.

Cela n'empeche pas d'avoir une idee de la limite inferieure du travail a
fournir. Quand on est confronte pragmatiquement a la question il est clair que
cette limite peut augmenter beaucoup. Ceci dit j'ai pas besoin d'etre un expert
pour savoir qu'une voiture est plus compliquee qu'un velo.

| Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| Mis a part _Bool, long long, _Complex et les varlen array (en general
| deja tous supportes en 1999 avec une semantique proche) et la
| foultitude de types, macros et autres fonctions a ajoutees dans la
| libc et qui demande surtout du temps et de la main d'oeuvre? Par
| contre il y avait enormement a faire entre le C++ existant au moment
| de la sortie de C++98 et le C++ qu'elle specifie.

À part l'arrogance des assertions,

Il n'y a ni arrogance, ni assertion. Toutes les phrases ont un ? et c'est ton
avis que je voulais puisque tu es implique dans le development de GCC.

je remarque surtout une ignorance

Certe.

complète des difficultés que soulèvent la nouvelle définition de C.
Les tableaux à taille variable (VLA) posent plus de problèmes que tu

- alloca a une semantique tres proche des VLA, des solutions pratiques
existaient donc deja en 99 et meme avant.
- les VMT posent effectivement des problemes et demandent de modifier le systeme
de typage en profondeur, mais techniquement ce n'est pas un probleme inconnu et
encore jamais resolu.
- il faut modifier la syntaxe et la grammaire ce qui pour des experts en
compilateur ne devrait pas poser trop de probleme.
- ??

ne sembles le croire. La nouvelle sémantique des opérations flottantes
est au moins de deux ordres de magnitude difficiles à supporter qu'un
pendant en C++ avec une volution bibliothèque. C'est encore plus

Si tu fais allusion a la classe complex, elle sera consideree comme une heresie
par certains experts mais (me) suffira dans 99.9% des cas pratiques. A l'oppose,
C99 a voulu etre plus precis et stricte rendant l'implementation ardue alors que
le fruit etait deja verole.

Et il me semble que numeric_limits n'a pas non plus ete simple a mettre au point...

Mais je ne t'apprends rien, je sais que tu es un expert sur ces deux sujets.

difficile qu'il faut modifier profondément l'architecture de nombre de
compilateurs majeurs existants. Comment implémentes-tu les
type-generic macros?

une magie tu meme genre que typeof? Ce qui est propose dans le ACRM d'Harbison
n'est clairement pas adapte.

Il est facile de dire que l'implémentation des nouvelles fonctions de
la bibliothèque ne nécessite que de la main de d'oeuvre et du temps.
Mais la pratique est toute autre. Il ne suffit pas seulement d'avoir
de la main d'oeuvre et du temps. Et de fait, la main d'oeuvre et du
temps sont à comptabiliser dans « effort ». En attandant et les gens
de C99 aient « le temps et la main d'oeuvre » , l'implémentation de
C++98 progresse et est presque terminée, et c'est ce qui compte.

| > | Cela ne veut pas dire que C++98 ne sera pas supportee avant C99.
| > je prédis que C++98 serait bien mieux supporté avant C99.
|
| Pas de contradiction avec ce que je dis.

non ton affirmation n'exclut pas le cas contraire non plus. La plus
est plus décisive. C'est la différence.

??

a+, ld.

--
[ Laurent Deniau -- Scientific Computing & Data Analysis ]
[ CERN -- European Center for Nuclear Research ]
[ Laurent.Deniau@cern.ch - http://cern.ch/Laurent.Deniau ]
[ -- One becomes old when dreams become regrets -- ]

Gabriel Dos Reis wrote:

Laurent Deniau <Laurent.Deniau@cern.ch> writes:


| Mon principe est qu'en lisant une fois une interface (un header) on devrait

Mauvais principe, changer de principe.

Les gens devraient pas lire les en-têtes, mais les spécifications et
les documentations.

Corollaire : les developpeurs devraient rediger des documentations qui
rendent inutiles la lecture des en tete. Ce n'est malheureusement le
cas. Petit exemple documentation de l'objet gtk_style de la librairie
Gtk+ 1.2 :

| The style object
| =============== |
| Description
| -----------
|
| Functions
| ---------

Si tu arrive a developper quelque chose avec ca sans consulter les
headers, je t'offre le resto (mais pas l'avion pour venir ici quand meme)

Sans compter des trucs du style : telle fonction retourne un pointeur.
Tu en fait quoi tu l'efface apres usage ou il ne faut surtout pas parce
qu'il pointe sur des données internes de la librairie, etc... Et la
c'est plus les en tete que tu dois lire pour savoir mais carrement les
sources.

Il est vrai que la doc d'un des outils les plus populaire (doxygen) est
encore pire et parfois on a des trucs etranges, comme tous mes membres
de classes qui ont été reclassifié en fonctions normales par le
programme alors que rien dans la doc ne laissait presager ce genre de
comportement.


C'etait mon coup de gueule contre les developpeurs paresseux (dont je
fais partie, mais je me soigne).


A+

LD

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > | > | > de 1999 est sans doute nettement moins implémentée que la norme
| > | > ISO C++98.
| > | > | | Certes, mais l'effort a fournir pour que C99 soit supporte est
| > | > bien
| > | > | moindre que pour C++98.
| > | >
| > | > qu'est-ce que tu en sais ?
| > | | Pretendre le contraire serait pour l'occasion de la vraie
| > mauvaise
| > | foi.
| > Pas du tout. As-tu implémenté l'une ou les deux spécifications ?
|
| Non. Toi non plus.

J'ai travaillé (et travaille toujours) sur l'implémentation des deux
-- cela fait partie de mon gagne pain.

| En dehors d'etre provocatrice, cette question est
| inutile et je ne te suivrais pas dans ce jeux la. Peu de gens (s'il en
| existe) ont implemente eux-meme l'une ou l'autre de ses specifications
| (ou une version anterieure) dans leur totalite.

Cette question n'est ni provocatrice ni inutile. Elle vise å savoir
quelle expérience tu as de l'implémentation de l'une des deux. Ton
inexpérience en l'implémentation de l'une des deux spécifications, ne
fait pas de la question posée quelque chose d'inutile ou provocateur.

| Cela n'empeche pas d'avoir une idee de la limite inferieure du travail
| a fournir.

Comme un téléspectateur qui pense savoir jouer au foot rien qu'en
regardant la télé ? Bien sûr tu peux penser avoir une idée de la
complexité de la chose, mais je suis prêt à parier que ton idée est à
des années-lumière de la réalité.

| Quand on est confronte pragmatiquement a la question il est
| clair que cette limite peut augmenter beaucoup. Ceci dit j'ai pas
| besoin d'etre un expert pour savoir qu'une voiture est plus compliquee
| qu'un velo.

sauf qu'il ne s'agit pas de construction de vélo ou de voiture.

| > | Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| > | qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| > | Mis a part _Bool, long long, _Complex et les varlen array (en general
| > | deja tous supportes en 1999 avec une semantique proche) et la
| > | foultitude de types, macros et autres fonctions a ajoutees dans la
| > | libc et qui demande surtout du temps et de la main d'oeuvre? Par
| > | contre il y avait enormement a faire entre le C++ existant au moment
| > | de la sortie de C++98 et le C++ qu'elle specifie.
| > À part l'arrogance des assertions,
|
| Il n'y a ni arrogance, ni assertion. Toutes les phrases ont un ? et

Tu n'es pas sans ignorance qu'une phrase qui se termine pas un point
d'interrogation n'implique ni arrogance, ni assertion ; n'est-il pas ?

| c'est ton avis que je voulais puisque tu es implique dans le
| development de GCC.

et je te l'ai donné.

| > je remarque surtout une ignorance
|
| Certe.
|
| > complète des difficultés que soulèvent la nouvelle définition de C.
| > Les tableaux à taille variable (VLA) posent plus de problèmes que tu
|
| - alloca a une semantique tres proche des VLA, des solutions pratiques
| existaient donc deja en 99 et meme avant.

« très proche » dépend de ta définition de « proche ».
Relis la spécification des VLA (sans préjugé aucun sur ce que tu
connias d'alloca) et tu te rendras compte alloca est aussi proche des
VLA que uranus est proche du soleil.

| - les VMT posent effectivement des problemes et demandent de modifier
| le systeme de typage en profondeur, mais techniquement ce n'est pas un
| probleme inconnu et encore jamais resolu.

La plupart des compilateurs à vocation industrielle ne sont pas des
gadgets universitaires jetables après première utilisation. Ce sont
des logiciels évolutifs où chaque version est le fruit d'itérations
sur la version précédente. Le compilateur évolue mais garde un fond
plus ou moins immuable, basé sur une certaine compréhension de la
machine abstraite C et son système de types. Les VMT viennent
bouleverser cela, et en profoondeur. Concrètement, cela veut dire que
pour la plupart des compilateurs, il faut revoir la machinerie qui
fait la vérification sémantique, la conception du système de type et
interaction avec les extensions (tout le monde est contre et tout le
monde en veut). Ce sont des problèmes pratiques que l'univeristaire
dans son labo ne considère pas -- probablement parce qu'il vit dans un
monde parallèle. Mais le fabriquant de compilateur ne peut pas les
ignorer. Il doit les résoudre, assez rapidement. La question n'est pas
qu'il n'existe pas un papier académique qui prétend traiter le sujet
dans un cadre de travail ultra simplifié, c'est que l'universitaire
n'a qu'une vision très parcellaire du langage, des fonctionnalités et
des contraintes pratiques. Des choses qu'on ne traite en général pas
dans les papiers académiques. Ce qui laisse souvent dire que le
problèment est techniquement résoluble et donc qu'il n'y a pas de
problème. C'est-à-dire une ignorance de la réalité.

| - il faut modifier la syntaxe et la grammaire ce qui pour des experts
| en compilateur ne devrait pas poser trop de probleme.

cette phrase est encore un morceau d'illustration de ton arrogane et
ton ignorance (et tu le fais exprès). Yaka. Faucon.

| - ??
|
| > ne sembles le croire. La nouvelle sémantique des opérations flottantes
| > est au moins de deux ordres de magnitude difficiles à supporter qu'un
| > pendant en C++ avec une volution bibliothèque. C'est encore plus
|
| Si tu fais allusion a la classe complex,

Non. Je fais allusion au fait que le langage aurait dû fournir des
fonctionnalités assez générales pour faciliter des solutions
bibliothèques efficaces, au lieu de mettre en dur des fonctionnalités
qui au fond ne profite qu'à une fraction de la communauté.

| elle sera consideree comme une heresie par certains experts

qu'est-ce qui en ferait une hérésie selon ces « certains experts » ?

| mais (me) suffira dans 99.9% des cas
| pratiques. A l'oppose, C99 a voulu etre plus precis et stricte rendant
| l'implementation ardue alors que le fruit etait deja verole.

Explique-toi.

| Et il me semble que numeric_limits n'a pas non plus ete simple a
| mettre au point...

Explique-toi.

| Mais je ne t'apprends rien, je sais que tu es un expert sur ces deux sujets.

En fait, je suis curieux d'en savoir un peu plus sur ces allusions vagues.

|
| > difficile qu'il faut modifier profondément l'architecture de nombre
| > de compilateurs majeurs existants. Comment implémentes-tu les
| > type-generic macros?
|
| une magie tu meme genre que typeof?

Non. Une fois que tu as le typeof, qu'est-ce que tu en fais ?

| Ce qui est propose dans le ACRM
| d'Harbison n'est clairement pas adapte.

Clairement.

-- Gaby

Laurent DELEPINE <newsgroup@webiologie.org> writes:

| Gabriel Dos Reis wrote:
| > Laurent Deniau <Laurent.Deniau@cern.ch> writes:
| > | Mon principe est qu'en lisant une fois une interface (un
| > header) on devrait
| > Mauvais principe, changer de principe.
| > Les gens devraient pas lire les en-têtes, mais les spécifications et
| > les documentations.
|
| Corollaire : les developpeurs devraient rediger des documentations qui
| rendent inutiles la lecture des en tete.

Exact.

| Ce n'est malheureusement le cas.

oui, et je pense qu'il faut soigner le mal. On n'érige pas la conduite
de chauffard en règle simplement parce que certains conducteurs sont
des chauffards.

[...]

| C'etait mon coup de gueule contre les developpeurs paresseux

coup de gueule que je comprends.

-- Gaby

Laurent Deniau <Laurent.Deniau@cern.ch> writes:

| Gabriel Dos Reis wrote:
| > | > | > de 1999 est sans doute nettement moins implémentée que la norme
| > | > ISO C++98.
| > | > | | Certes, mais l'effort a fournir pour que C99 soit supporte est
| > | > bien
| > | > | moindre que pour C++98.
| > | >
| > | > qu'est-ce que tu en sais ?
| > | | Pretendre le contraire serait pour l'occasion de la vraie
| > mauvaise
| > | foi.
| > Pas du tout. As-tu implémenté l'une ou les deux spécifications ?
|
| Non. Toi non plus.

J'ai travaillé (et travaille toujours) sur l'implémentation des deux
-- cela fait partie de mon gagne pain.

| En dehors d'etre provocatrice, cette question est
| inutile et je ne te suivrais pas dans ce jeux la. Peu de gens (s'il en
| existe) ont implemente eux-meme l'une ou l'autre de ses specifications
| (ou une version anterieure) dans leur totalite.

Cette question n'est ni provocatrice ni inutile. Elle vise å savoir
quelle expérience tu as de l'implémentation de l'une des deux. Ton
inexpérience en l'implémentation de l'une des deux spécifications, ne
fait pas de la question posée quelque chose d'inutile ou provocateur.

| Cela n'empeche pas d'avoir une idee de la limite inferieure du travail
| a fournir.

Comme un téléspectateur qui pense savoir jouer au foot rien qu'en
regardant la télé ? Bien sûr tu peux penser avoir une idée de la
complexité de la chose, mais je suis prêt à parier que ton idée est à
des années-lumière de la réalité.

| Quand on est confronte pragmatiquement a la question il est
| clair que cette limite peut augmenter beaucoup. Ceci dit j'ai pas
| besoin d'etre un expert pour savoir qu'une voiture est plus compliquee
| qu'un velo.

sauf qu'il ne s'agit pas de construction de vélo ou de voiture.

| > | Sans ironie, qu'est ce qui serait une avancee majeure dans C99 et
| > | qui demanderait tant de travail par rapport a C89 (ou C95) selon toi?
| > | Mis a part _Bool, long long, _Complex et les varlen array (en general
| > | deja tous supportes en 1999 avec une semantique proche) et la
| > | foultitude de types, macros et autres fonctions a ajoutees dans la
| > | libc et qui demande surtout du temps et de la main d'oeuvre? Par
| > | contre il y avait enormement a faire entre le C++ existant au moment
| > | de la sortie de C++98 et le C++ qu'elle specifie.
| > À part l'arrogance des assertions,
|
| Il n'y a ni arrogance, ni assertion. Toutes les phrases ont un ? et

Tu n'es pas sans ignorance qu'une phrase qui se termine pas un point
d'interrogation peut impliquer arrogance, assertion ; n'est-il pas ?

| c'est ton avis que je voulais puisque tu es implique dans le
| development de GCC.

et je te l'ai donné.

| > je remarque surtout une ignorance
|
| Certe.
|
| > complète des difficultés que soulèvent la nouvelle définition de C.
| > Les tableaux à taille variable (VLA) posent plus de problèmes que tu
|
| - alloca a une semantique tres proche des VLA, des solutions pratiques
| existaient donc deja en 99 et meme avant.

« très proche » dépend de ta définition de « proche ».
Relis la spécification des VLA (sans préjugé aucun sur ce que tu
connias d'alloca) et tu te rendras compte alloca est aussi proche des
VLA que uranus est proche du soleil.

| - les VMT posent effectivement des problemes et demandent de modifier
| le systeme de typage en profondeur, mais techniquement ce n'est pas un
| probleme inconnu et encore jamais resolu.

La plupart des compilateurs à vocation industrielle ne sont pas des
gadgets universitaires jetables après première utilisation. Ce sont
des logiciels évolutifs où chaque version est le fruit d'itérations
sur la version précédente. Le compilateur évolue mais garde un fond
plus ou moins immuable, basé sur une certaine compréhension de la
machine abstraite C et son système de types. Les VMT viennent
bouleverser cela, et en profoondeur. Concrètement, cela veut dire que
pour la plupart des compilateurs, il faut revoir la machinerie qui
fait la vérification sémantique, la conception du système de type et
interaction avec les extensions (tout le monde est contre et tout le
monde en veut). Ce sont des problèmes pratiques que l'univeristaire
dans son labo ne considère pas -- probablement parce qu'il vit dans un
monde parallèle. Mais le fabriquant de compilateur ne peut pas les
ignorer. Il doit les résoudre, assez rapidement. La question n'est pas
qu'il n'existe pas un papier académique qui prétend traiter le sujet
dans un cadre de travail ultra simplifié, c'est que l'universitaire
n'a qu'une vision très parcellaire du langage, des fonctionnalités et
des contraintes pratiques. Des choses qu'on ne traite en général pas
dans les papiers académiques. Ce qui laisse souvent dire que le
problèment est techniquement résoluble et donc qu'il n'y a pas de
problème. C'est-à-dire une ignorance de la réalité.

| - il faut modifier la syntaxe et la grammaire ce qui pour des experts
| en compilateur ne devrait pas poser trop de probleme.

cette phrase est encore un morceau d'illustration de ton arrogane et
ton ignorance (et tu le fais exprès). Yaka. Faucon.

| - ??
|
| > ne sembles le croire. La nouvelle sémantique des opérations flottantes
| > est au moins de deux ordres de magnitude difficiles à supporter qu'un
| > pendant en C++ avec une volution bibliothèque. C'est encore plus
|
| Si tu fais allusion a la classe complex,

Non. Je fais allusion au fait que le langage aurait dû fournir des
fonctionnalités assez générales pour faciliter des solutions
bibliothèques efficaces, au lieu de mettre en dur des fonctionnalités
qui au fond ne profite qu'à une fraction de la communauté.

| elle sera consideree comme une heresie par certains experts

qu'est-ce qui en ferait une hérésie selon ces « certains experts » ?

| mais (me) suffira dans 99.9% des cas
| pratiques. A l'oppose, C99 a voulu etre plus precis et stricte rendant
| l'implementation ardue alors que le fruit etait deja verole.

Explique-toi.

| Et il me semble que numeric_limits n'a pas non plus ete simple a
| mettre au point...

Explique-toi.

| Mais je ne t'apprends rien, je sais que tu es un expert sur ces deux sujets.

En fait, je suis curieux d'en savoir un peu plus sur ces allusions vagues.

|
| > difficile qu'il faut modifier profondément l'architecture de nombre
| > de compilateurs majeurs existants. Comment implémentes-tu les
| > type-generic macros?
|
| une magie tu meme genre que typeof?

Non. Une fois que tu as le typeof, qu'est-ce que tu en fais ?

| Ce qui est propose dans le ACRM
| d'Harbison n'est clairement pas adapte.

Clairement.

-- Gaby