C++0x
Gabriel Dos Reis
La pre-mailing pour Oxford est disponible depuis quelques jours.
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford
Le papier "Why We Can't Afford Export" est « intéressant. ».
-- Gaby
Jean-Marc Bourguet
Petit commentaire rapide, resultant de mon experimentation; note:
celle-ci est personnelle et pas dans le cadre de mon travail.
2.3/ Phantom advantage 2:fast build, reduced dependancies.
Je doute que ce soit un avantage fantome: je l'ai mesure. Uniquement
sur des exemples artificiels mais je n'ai pas l'impression qu'ils ne
sont pas hors norme. Les deux parametres sont la quantite de code que
l'utilisation d'export evite d'inclure et le nombre d'unite de
compilation utilisant une instantiation. Plus ces parametres sont
grands, plus export est interessant.
L'important est que cet avantage depend aussi du modele
d'instanciation. Ce n'en n'est reellement un qu'avec un modele global
(comme HP, comeau). Dans un modele local avec cache (genre Sun), ce
doit etre un avantage. Dans un modele local avec duplication eliminee
par le linker (genre Borland, gcc), c'est effectivement une perte.
2.5/ example 3: au moins dans l'implementation de Comeau, les
makefiles sont triviaux a ecrire (autrement dit l'equivalent de g++
-MM suffit pour generer toutes les dependances) et il n'y a pas de
dependances generees entre les fichiers d'implementation et les
fichiers instantiant. Les recompilations necessaires sont traitees
correctement par le pre-linker.
A nouveau, c'est vrai pour un modele d'instantiation global. Dans
un modele local, les dependances ce doit etre un probleme.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis
| Gabriel Dos Reis <g...@integrable-solutions.net> writes:
|
| > La pre-mailing pour Oxford est disponible depuis quelques jours.
| >
| > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford
| >
| > Le papier "Why We Can't Afford Export" est « intéressant. ».
|
| Petit commentaire rapide, resultant de mon experimentation; note:
commentaire que je trouve très intéressant.
Pour être plus clair, je crois que la prochaine réunion à Oxford va
être très tendue car je crois qu'il y a réellement un mini-putch qui
se prépare et que les gens sont en train de faire les décomptes.
Cela ne me plaît pas du tout.
Bien que je ne sois pas un supporter inconditionnel de « export », je
ne crois pas non plus que ce soit responsable de vouloir enlever
quelque comme cela de la norme sur des bases très peu claires (je ne
considère pas un article de marketing dans un journal comme une
justification solide) et qu'à la place on ne propose rien. Il y a un
réel problème qu'il faut résoudre -- compilation séparée des templates
--, enlever export ne résoud pas ce problème.
C'est une raison pour laquelle j'ai besoin de savoir ce que les
utilisateurs qui fréquentent ce groupe pensent.
-- Gaby
Mickael Pointier
> Pour être plus clair, je crois que la prochaine réunion à Oxford va
> être très tendue car je crois qu'il y a réellement un mini-putch qui
> se prépare et que les gens sont en train de faire les décomptes.
>
> Cela ne me plaît pas du tout.
>
> Bien que je ne sois pas un supporter inconditionnel de « export », je
> ne crois pas non plus que ce soit responsable de vouloir enlever
> quelque comme cela de la norme sur des bases très peu claires (je ne
> considère pas un article de marketing dans un journal comme une
> justification solide) et qu'à la place on ne propose rien. Il y a un
> réel problème qu'il faut résoudre -- compilation séparée des templates
> --, enlever export ne résoud pas ce problème.
Compiler séparément les templates est nécéssaire à quel niveau, pour
gagner en temps de compilation, ou pour pouvoir fournir des librairies
en C++ dont on puisse cacher l'intégralité du code source ?
> C'est une raison pour laquelle j'ai besoin de savoir ce que les
> utilisateurs qui fréquentent ce groupe pensent.
>
> -- Gaby
J'ai lu le PDF, mon impression à chaud c'est que c'est une feature
complexe à implémenter, difficile à utiliser, et qui proportionnelement
n'offre pas grand chose.
Quand je vois la qualité des compilos C++ qu'on se tappe actuellement
sur console alors qu'ils ne gèrent pas export, ca m'embeterais qu'on se
prennent encore des bugs dans la tête alors que les fonctionalité
standard sont encore buggées jusqu'a l'os ;)
Mike
Christophe de Vienne
>> [...]
>> Pour être plus clair, je crois que la prochaine réunion à Oxford va
>> être très tendue car je crois qu'il y a réellement un mini-putch qui
>> se prépare et que les gens sont en train de faire les décomptes.
>>
>> Cela ne me plaît pas du tout.
>>
>> Bien que je ne sois pas un supporter inconditionnel de « export », je
>> ne crois pas non plus que ce soit responsable de vouloir enlever
>> quelque comme cela de la norme sur des bases très peu claires (je ne
>> considère pas un article de marketing dans un journal comme une
>> justification solide) et qu'à la place on ne propose rien. Il y a un
>> réel problème qu'il faut résoudre -- compilation séparée des templates
>> --, enlever export ne résoud pas ce problème.
>
> Compiler séparément les templates est nécéssaire à quel niveau, pour
> gagner en temps de compilation, ou pour pouvoir fournir des librairies
> en C++ dont on puisse cacher l'intégralité du code source ?
>
Peut-être aussi pour fournir des librairies qui peuvent être mises à jour
sans recompiler toutes les applications qui les utilisent, dans le cas d'un
bugfix mineur notament.
Ce problème fait débat sur la mailing de libxml++ : on est sur le point de
faire deux versions de la lib : une entièrement templatée, une autre qui ne
l'est pas, et tout ça à cause de ce problème...
Cela dit je ne suis pas sûr qu'export tel qu'il est défini apporterais une
solution à ce problème, à moins que le link dynamique des librairies ne se
complexifie considérablement j'imagine.
Christophe
--
Christophe de Vienne
Experience is something you don't get until just after you need it.
Oliver's Law.
Mickael Pointier
>> gagner en temps de compilation, ou pour pouvoir fournir des
>> librairies en C++ dont on puisse cacher l'intégralité du code source
>> ?
>
> Peut-être aussi pour fournir des librairies qui peuvent être mises à
> jour sans recompiler toutes les applications qui les utilisent, dans
> le cas d'un bugfix mineur notament.
Parce que le code est dans le header, et que donc un changement
d'implémentation, même s'il n'implique pas de changement dans
l'interface fait que le .H a été modifié, et que donc il faut tout
rebuilder. C'est bien ca le problème ?
C'est un peu le même genre de problématique que pour les méthodes
inlines dans une classe non ? On se retrouve à mélanger implémentation
et interface, et donc à rebuilder des choses alors que rien de
significatif pour le client n'a été modifié.
> Ce problème fait débat sur la mailing de libxml++ : on est sur le
> point de faire deux versions de la lib : une entièrement templatée,
> une autre qui ne l'est pas, et tout ça à cause de ce problème...
> Cela dit je ne suis pas sûr qu'export tel qu'il est défini
> apporterais une solution à ce problème, à moins que le link dynamique
> des librairies ne se complexifie considérablement j'imagine.
Il faudrait peut-être plus voir une solution globale au niveau de la
compatibilité binaire des modules compilés/librairies, et éventuellement
envisager un pseudo format binarisé pour les templates, style stocker un
AST dans un format standardisé ?
Mike
James Kanze
news:<m3ptoy1...@uniton.integrable-solutions.net>...
> La pre-mailing pour Oxford est disponible depuis quelques jours.
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford
> Le papier "Why We Can't Afford Export" est « intéressant. ».
Ainsi que le nombre de papiers sur des extensions possibles. Comme si on
arrivait déjà à utiliser (ou à implémenter) tout ce qu'il y a.
(En ce qui concerne le papier dont tu parles, c'est intéressant que tous
les arguments contre s'appuie sur les dires des autres. On se pose la
question alors pourquoi ces autres n'ont pas écrit le papier.)
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, Tél. : +33 (0)1 30 23 45 16
Gabriel Dos Reis
| Gabriel Dos Reis <g...@integrable-solutions.net> wrote in message
| news:<m3ptoy1...@uniton.integrable-solutions.net>...
| > La pre-mailing pour Oxford est disponible depuis quelques jours.
|
| > http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford
|
| > Le papier "Why We Can't Afford Export" est « intéressant. ».
|
| Ainsi que le nombre de papiers sur des extensions possibles. Comme si on
| arrivait déjà à utiliser (ou à implémenter) tout ce qu'il y a.
En fait, le reste des papiers sur les extensions m'inquiète moins que
celui que je mentionnais : celui-là me paraît une instrumentatlisation
du comité.
| (En ce qui concerne le papier dont tu parles, c'est intéressant que tous
| les arguments contre s'appuie sur les dires des autres. On se pose la
| question alors pourquoi ces autres n'ont pas écrit le papier.)
Je connais au moins une des personnes citées qui est violamment contre
le papier et la manière dont il est redigé, qui tendrait à faire croire
qu'elle est d'accord alors qu'elle ne l'est pas.
-- Gaby
Michel Michaud
message de news: m34r6ag...@uniton.integrable-solutions.net...
> Je connais au moins une des personnes citées qui est violamment
> contre le papier et la manière dont il est redigé, qui tendrait à
> faire croire qu'elle est d'accord alors qu'elle ne l'est pas.
D'un autre côté, Sutter travaille maintenant pour une compagnie qui
économiserait en n'implantant pas export ? Je crois qu'on cherche
à faire un procès d'intentions...
Ce qui est dit dans l'article n'est pas absurde et ceux qui ont
travaillé fort pour avoir un export fonctionnel seraient les plus
grands perdants si export était banni. C'est normal d'être contre
dans ce cas.
Est-ce qu'il y a du « faux » dans l'article ? Si ce n'est pas le
cas, pour le commun des mortels, il semble clair que export peut
être enlevé. Doit-il l'être ? Si ça nuit au reste du langage, comme
l'article semble le dire, alors oui...
Alors discutons de la véracité de l'article !
Pour le moment, je ne suis ni pour ni contre, bien au contraire...
--
Michel Michaud
michel....@cstjean.qc.ca
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
| "Gabriel Dos Reis" <g...@integrable-solutions.net> a écrit dans le
| message de news: m34r6ag...@uniton.integrable-solutions.net...
| > Je connais au moins une des personnes citées qui est violamment
| > contre le papier et la manière dont il est redigé, qui tendrait à
| > faire croire qu'elle est d'accord alors qu'elle ne l'est pas.
|
| D'un autre côté, Sutter travaille maintenant pour une compagnie qui
| économiserait en n'implantant pas export ? Je crois qu'on cherche
| à faire un procès d'intentions...
Je ne cherche pas à faire des procès d'intention.
Voici des *faits* :
1) Il n'y a pas longtemps, Herb nous disait très fort que son
employeur est la seule compagnie à avoir dit plubliquement (à
part évidemment EDG) qu'ils implenteraient « export. »
2) Entre temps Herb écrit des articles pour nous expliquer que
« export » est Mal
3) Un an après le « public commitment », Herb nous explique qu'il
faut enlever « export ».
Je ne peux m'empêcher de m'interroger lorsque je vois que son employeur
avait qu'ils auraient *bientôt* un compilateur 100% conforme et que
maintenant parmi les arguments avancés par Herb contre « export »,
c'est que la compagnie de trois personnes qui a implémenté « export »
dit que cela leur a pris du temps.
| Ce qui est dit dans l'article n'est pas absurde
As-tu des preuves ?
| et ceux qui ont
| travaillé fort pour avoir un export fonctionnel seraient les plus
| grands perdants si export était banni.
Si seulement cela était vrai.
| C'est normal d'être contre dans ce cas.
|
| Est-ce qu'il y a du « faux » dans l'article ?
Il y a beaucoup d'exagération dans cet article. Voir le message de
Jean-Marc par exemple.
C'est un peu comme si quelqu'un te dit : C++ est complexe donc il
est inutilisable.
-- Gaby
Christophe de Vienne
>>> Compiler séparément les templates est nécéssaire à quel niveau, pour
>>> gagner en temps de compilation, ou pour pouvoir fournir des
>>> librairies en C++ dont on puisse cacher l'intégralité du code source
>>> ?
>>
>> Peut-être aussi pour fournir des librairies qui peuvent être mises à
>> jour sans recompiler toutes les applications qui les utilisent, dans
>> le cas d'un bugfix mineur notament.
>
> Parce que le code est dans le header, et que donc un changement
> d'implémentation, même s'il n'implique pas de changement dans
> l'interface fait que le .H a été modifié, et que donc il faut tout
> rebuilder. C'est bien ca le problème ?
>
> C'est un peu le même genre de problématique que pour les méthodes
> inlines dans une classe non ? On se retrouve à mélanger implémentation
> et interface, et donc à rebuilder des choses alors que rien de
> significatif pour le client n'a été modifié.
Dans ce cas la solution est simple : ne pas faire d'inline. Et ils sont
rares me semble-t-il pour une librairie.
>
>
>> Ce problème fait débat sur la mailing de libxml++ : on est sur le
>> point de faire deux versions de la lib : une entièrement templatée,
>> une autre qui ne l'est pas, et tout ça à cause de ce problème...
>> Cela dit je ne suis pas sûr qu'export tel qu'il est défini
>> apporterais une solution à ce problème, à moins que le link dynamique
>> des librairies ne se complexifie considérablement j'imagine.
>
> Il faudrait peut-être plus voir une solution globale au niveau de la
> compatibilité binaire des modules compilés/librairies, et éventuellement
> envisager un pseudo format binarisé pour les templates, style stocker un
> AST dans un format standardisé ?
Mais cela sous-entend, dans le cas que je cite, que tu transformes ton
pseudo format binarisé en format définitif au moment du lien dynamique,
donc à chaque execution du programme. Cela ne risque pas d'arranger le
temps de lancement d'une appli C++ un peu grosse, qui est déjà assez
long...
Christophe Lephay
news: gxnba.186$S53....@news20.bellglobal.com...
> Pour le moment, je ne suis ni pour ni contre, bien au contraire...
Lol c'est le titre d'un film français actuellement sur nos écrans (sur les
votres-au Québec- aussi ?)
Chris
Jean-Marc Bourguet
> Est-ce qu'il y a du « faux » dans l'article ?
1/ export reduit les dependances. Il y a des modeles d'instanciations
qui ne peuvent pas profiter de cette reduction mais c'est pas la faute
a export.
2/ export reduit le temps de compilation dans certains cas. Je ne l'ai
mesure que sur des exemples artificiels mais un de ceux-ci etait un
modele raisonnable du code auquel je serais vraissemblablement arrive
dans le seul cas ou j'ai eu envie d'utiliser des templates pour une
classe applicative (mes utilisations outre la SL sont plutot des
artefacts d'implementation) (le projet a ete mis en suspend pour des
raisons tout autre).
Je n'ai pas l'experience de code riche en templates, mais cet exemple
n'est pas un cas artificiellement construit pour etre avantageux (j'ai
naturellement commence par mesurer sur de tels exemples mais je
voulais voir si c'etait extrapolable au moins a certains cas proche de
la realite) et en tout cas pas quelque chose de difficile a imaginer.
Les deux facteurs qui font gagner, c'est le nombre d'unite de
compilation utilisant chaque instantiation et l'ampleur de la
reduction de la taille des entetes a inclure. Dans mon cas cette
reduction etait telle que deux unites utilisant une instantiation
donnait un avantage a export. (Je suis tombe sur un bug de Como quand
j'ai essaye de mesurer si l'avantage existait toujours avec des
en-tetes precompiles; ce bug est apparemment fixe dans la beta mais
j'ai pas eu le temps de refaire les mesures...)
A nouveau, ce gain depend du modele d'instantiation.
Example 3: Export puts new constraints on the build environment. The
build environment does not consist of just .cpp and .h files any
more. If you change an exported template file, you need to recompile
that, but you also need to recompile all the instantiations; that
is, export really does not separate dependencies, it just hides
them. Even experts like James Kanze find it hard to accept that
export really is like this.
export ne met pas de nouvelles contraintes sur l'environnement de
build. J'ai pu utiliser exactement les memes regles de makefile pour
compiler avec et sans export avec le compilateur de Comeau.
Ce qui est subtil dans la formulation ici c'est que oui, avec export
quand la definition change, il faut recompiler les instantiations
(James tu trouve reellement si dur d'admettre ca?). Non export ne
masque pas les dependances, car une instantiation n'a besoin d'etre
generee qu'une fois. Avec le modele d'inclusion, on se retappe la
compilation de toutes les unites de compilation incluant la definition
quel que soit le modele d'instantiation. Avec export et le modele
d'instantiation global (celui que Daveed appelle itere si j'ai bonne
memoire), on a la recompilation d'au maximum une unite de compilation
par instantiation utilisee (c'est possible que plusieurs soient
assignees a la meme unite de compilation).
Jean-Marc Bourguet
> ou pour pouvoir fournir des librairies en C++ dont on puisse cacher
> l'intégralité du code source?
Ce n'est pas le cas avec la seule implementation d'export. Voir mon
autre message sur le sujet.
Jean-Marc Bourguet
> Peut-être aussi pour fournir des librairies qui peuvent être mises à jour
> sans recompiler toutes les applications qui les utilisent, dans le cas d'un
> bugfix mineur notament.
Vraissemblablement pas plus complique sans export qu'avec.
Jean-Marc Bourguet
> Bien que je ne sois pas un supporter inconditionnel de « export »,
Je ne le suis pas non plus. Mon interet pour la compilation separee
des templates est esthetique et dans les dependances reduites (encore
que je ne suis pas sur que ce soit un gros avantage dans mon
environnement de travail). Je me suis amuse a experimenter avec et
j'ai constate que les avantages que j'en attendais etaient bien la.
> Il y a un réel problème qu'il faut résoudre -- compilation séparée
> des templates --, enlever export ne résoud pas ce problème.
La premiere question est la: qu'est-ce que les gens attendent de la
compilation separee?
Gabriel Dos Reis
| >> Compiler séparément les templates est nécéssaire à quel niveau, pour
| >> gagner en temps de compilation, ou pour pouvoir fournir des
| >> librairies en C++ dont on puisse cacher l'intégralité du code source
| >> ?
| >
| > Peut-être aussi pour fournir des librairies qui peuvent être mises à
| > jour sans recompiler toutes les applications qui les utilisent, dans
| > le cas d'un bugfix mineur notament.
|
| Parce que le code est dans le header, et que donc un changement
| d'implémentation, même s'il n'implique pas de changement dans
| l'interface fait que le .H a été modifié, et que donc il faut tout
| rebuilder. C'est bien ca le problème ?
Un peu, oui.
| C'est un peu le même genre de problématique que pour les méthodes
| inlines dans une classe non ?
Non, parce que dans le cas de « inline », le passage de inline à
non-inline ne présente pas le même coût, et cela reste une possibilité.
Et de plus, les fonctions inlines sont rarement (jamais ?) aussi
grosses que les implémentations des templates.
-- Gaby
Alexandre Abreu
> complexe à implémenter, difficile à utiliser, et qui proportionnelement
> n'offre pas grand chose.
je l'ai aussi parcouru et ma connaissance d'export s'arretait au noms et a
une idee
vague des buts recherches.
Une question qui me vient a l'esprit dans l'immediat est: y a t il des
groupes de
travail qui planchent sur une alternative ou sur une orientation differente
du
probleme ?
> Quand je vois la qualité des compilos C++ qu'on se tappe actuellement
> sur console alors qu'ils ne gèrent pas export, ca m'embeterais qu'on se
> prennent encore des bugs dans la tête alors que les fonctionalité
> standard sont encore buggées jusqu'a l'os ;)
Pas seulement pour les compilos console mais ne serait ce que pour les
compilos
plus classiques qui ne supportent meme pas pour certains beaucoup de
fonctionnalites
liees aux templates (sans parler du reste) ...
--
Alexandre Abreu
Michel Michaud
> message de news: b4l4di$r9k$1...@news-reader0.wanadoo.fr...
Non. C'est une vieille phrase de je-ne-me-souviens-plus-qui.
Christophe de Vienne
> Christophe de Vienne <cdevienn...@alphacent.nospam.com> writes:
>
>> Peut-être aussi pour fournir des librairies qui peuvent être mises à jour
>> sans recompiler toutes les applications qui les utilisent, dans le cas
>> d'un bugfix mineur notament.
>
> Vraissemblablement pas plus complique sans export qu'avec.
>
Là j'avoue ne pas comprendre ? On peut faire ça avec des classes templates ?
Même si elles sont instanciées par l'utilisateur ?
Jean-Marc Bourguet
> Jean-Marc Bourguet wrote:
>
> > Christophe de Vienne <cdevienn...@alphacent.nospam.com> writes:
> >
> >> Peut-être aussi pour fournir des librairies qui peuvent être
> >> mises à jour sans recompiler toutes les applications qui les
> >> utilisent, dans le cas d'un bugfix mineur notament.
> >
> > Vraissemblablement pas plus complique sans export qu'avec.
>
> Là j'avoue ne pas comprendre ? On peut faire ça avec des classes
> templates ? Même si elles sont instanciées par l'utilisateur ?
Dans les deux cas il faut mettre dans la bibliotheque toutes les
instantiations et demander une recompilation pour les instantiations
qui n'y sont pas presentes.
Le modele de compilation C++ des templates est tel qu'une
implementation partagee des templates (comme en Eiffel ou en Modula-3)
n'est pas possible en pratique et export ne change rien a ca. Le
concept de specialisation partielle par exemple interagirait
vraissemblablement tres mal avec une implementation partagee, ce qui
est ce qu'il faudrait pour pouvoir simplement changer une bibliotheque
(eventuellement dynamique). Mais on perd alors la
meta-programmation...
Christophe de Vienne
> Christophe de Vienne <cdevienn...@alphacent.nospam.com> writes:
>
>> Jean-Marc Bourguet wrote:
>>
>> > Christophe de Vienne <cdevienn...@alphacent.nospam.com> writes:
>> >
>> >> Peut-être aussi pour fournir des librairies qui peuvent être
>> >> mises à jour sans recompiler toutes les applications qui les
>> >> utilisent, dans le cas d'un bugfix mineur notament.
>> >
>> > Vraissemblablement pas plus complique sans export qu'avec.
>>
>> Là j'avoue ne pas comprendre ? On peut faire ça avec des classes
>> templates ? Même si elles sont instanciées par l'utilisateur ?
>
> Dans les deux cas il faut mettre dans la bibliotheque toutes les
> instantiations et demander une recompilation pour les instantiations
> qui n'y sont pas presentes.
>
> Le modele de compilation C++ des templates est tel qu'une
> implementation partagee des templates (comme en Eiffel ou en Modula-3)
> n'est pas possible en pratique et export ne change rien a ca. Le
> concept de specialisation partielle par exemple interagirait
> vraissemblablement tres mal avec une implementation partagee, ce qui
> est ce qu'il faudrait pour pouvoir simplement changer une bibliotheque
> (eventuellement dynamique). Mais on perd alors la
> meta-programmation...
>
Merci pour ces explications. C'est beaucoup plus clair maintenant...
Christophe
Arnaud Meurgues
> Voici des *faits* :
>
> 1) Il n'y a pas longtemps, Herb nous disait très fort que son
> employeur est la seule compagnie à avoir dit plubliquement (à
> part évidemment EDG) qu'ils implenteraient « export. »
C'est amusant, parce que ça paraît contradictoire avec l'introduction :
"
There is no known announced plan to
support export in any other commercially available compiler product.
"
En fait, il a sans doute raison si sa société a renoncé à vouloir
l'implémenter, mais c'est un constat d'échec (éventuellement
compréhensible et acceptable) qu'il aurait pu/du avoir l'honnêteté de citer.
> C'est un peu comme si quelqu'un te dit : C++ est complexe donc il
> est inutilisable.
Ben oui. Non ? ;-)
Arnaud
James Kanze
message news:<newscache$f4flbh$kxk$1...@guronzan.alphacent.com>...
> Mickael Pointier wrote:
> >>> Compiler séparément les templates est nécéssaire à quel niveau,
> >>> pour gagner en temps de compilation, ou pour pouvoir fournir des
> >>> librairies en C++ dont on puisse cacher l'intégralité du code
> >>> source ?
> >> Peut-être aussi pour fournir des librairies qui peuvent être mises
> >> à jour sans recompiler toutes les applications qui les utilisent,
> >> dans le cas d'un bugfix mineur notament.
> > Parce que le code est dans le header, et que donc un changement
> > d'implémentation, même s'il n'implique pas de changement dans
> > l'interface fait que le .H a été modifié, et que donc il faut tout
> > rebuilder. C'est bien ca le problème ?
Tout à fait. Et quand les sources comprenent des millions de lignes, et
plusieurs milliers de .cc, c'est un effet non negligeable.
> > C'est un peu le même genre de problématique que pour les méthodes
> > inlines dans une classe non ? On se retrouve à mélanger
> > implémentation et interface, et donc à rebuilder des choses alors
> > que rien de significatif pour le client n'a été modifié.
> Dans ce cas la solution est simple : ne pas faire d'inline. Et ils
> sont rares me semble-t-il pour une librairie.
En effet. C'est ma politique : jamais d'inline (sauf, évidemment, si le
profiler dit qu'il le faut).
C'est actuellement aussi ma politique vis-à-vis des templates dans le
code de production : jamais de templates.
Me priver de inline, ça ne me coûte pas grand chose au niveau de
l'architecture et de la conception.
Me priver des templates, ça me coûte très cher. Trop cher, en fait --
dans la réalité, je ne m'en prive pas. Mais je limite l'utilisation au
maximum, et je cherche à l'isoler dans des classes fondamentales qui
doivent être, par leur nature même, ultra stable. Je le banis encore au
niveau des classes « métier ».
Arnaud Meurgues
>>Pour le moment, je ne suis ni pour ni contre, bien au contraire...
> Lol c'est le titre d'un film français actuellement sur nos écrans (sur les
> votres-au Québec- aussi ?)
C'est aussi une citation de Coluche, (mais je me demande si Coluche ne
l'avait pas repris de Pierre Dac).
Arnaud
James Kanze
> "Mickael Pointier" <mpoi...@eden-studios.fr> writes:
> Un peu, oui.
Surtout, tu n'es jamais obligé de t'en servir. Qu'une fonction soit
inline ou non ne change rien par rapport à l'architecture ou la
conception de l'application. Si tu constates qu'une fonction inline
change trop souvent, et mène à des temps de compilation trop longs, tu
peux le changer en non inline, sans changer quoique ce soit d'autre. Tu
ne peux pas en faire autant avec des templates.
James Kanze
news:<pxbvfyp...@news.bourguet.org>...
> Example 3: Export puts new constraints on the build environment. The
> build environment does not consist of just .cpp and .h files any
> more. If you change an exported template file, you need to recompile
> that, but you also need to recompile all the instantiations; that
> is, export really does not separate dependencies, it just hides
> them. Even experts like James Kanze find it hard to accept that
> export really is like this.
> export ne met pas de nouvelles contraintes sur l'environnement de
> build. J'ai pu utiliser exactement les memes regles de makefile pour
> compiler avec et sans export avec le compilateur de Comeau.
> Ce qui est subtil dans la formulation ici c'est que oui, avec export
> quand la definition change, il faut recompiler les instantiations
> (James tu trouve reellement si dur d'admettre ca?).
Au contraire. Il m'a toujours semblé évident que si l'implémentation
d'un template change, il faut récompiler les instantiations. Ce que je
veux éviter (et qu'apparamment export fait en partie, même dans
l'implémentation de EDG), c'est de récompiler tout le code client.
> Non export ne masque pas les dependances, car une instantiation n'a
> besoin d'etre generee qu'une fois. Avec le modele d'inclusion, on se
> retappe la compilation de toutes les unites de compilation incluant la
> definition quel que soit le modele d'instantiation. Avec export et le
> modele d'instantiation global (celui que Daveed appelle itere si j'ai
> bonne memoire), on a la recompilation d'au maximum une unite de
> compilation par instantiation utilisee (c'est possible que plusieurs
> soient assignees a la meme unite de compilation).
En passant, ce que tu as mésurer correspond à peu près à ce qu'a dit
Pete Becker en ce qui concerne ses expériences avec export.
Mon impression, c'est que l'opinion de ceux qui ont réelement utilisé
export, c'est que ça n'apporte pas autant qu'on aurait voulu (ou qu'on
aurait pu vouloir), mais que c'est toujours mieux que rien.
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
|
| > Voici des *faits* :
| > 1) Il n'y a pas longtemps, Herb nous disait très fort que son
| > employeur est la seule compagnie à avoir dit plubliquement (à
| > part évidemment EDG) qu'ils implenteraient « export. »
|
| C'est amusant, parce que ça paraît contradictoire avec l'introduction :
| "
| There is no known announced plan to
| support export in any other commercially available compiler product.
| "
De:
Je cite :
Microsoft is the only vendor I know of, besides EDG and Comeau, who
has publicly *committed* to implementing export.
-- Gaby
Arnaud Meurgues
> | "
> | There is no known announced plan to
> | support export in any other commercially available compiler product.
> | "
> Microsoft is the only vendor I know of, besides EDG and Comeau, who
> has publicly *committed* to implementing export.
Merci. Il y a donc bien une flagrante contradiction. Comment la résoud-il ?
Microsoft a-t-il publiquement abandonné le projet d'implémenter export ?
Arnaud
Arnaud Debaene
> Peut-être aussi pour fournir des librairies qui peuvent être mises à jour
> sans recompiler toutes les applications qui les utilisent, dans le cas d'un
> bugfix mineur notament.
Cet argument ne tient que si le "format intermédiaire" d'export peut
être déployé dans une librairie dynamique, ce qui me semble
extrêmement peu probable.
Dans le cas contraire (librairie statique), il faudra toujours
relinker les applications utilisant la librairie, et on ne changera
rien au problème principal, à savoir la distribution de la version
corrigée du logiciel.
Arnaud
Christophe de Vienne
> Christophe de Vienne <cdevienn...@alphacent.nospam.com> wrote in
> message news:<newscache$5g9lbh$j1k$1...@guronzan.alphacent.com>...
>
>
>> Peut-être aussi pour fournir des librairies qui peuvent être mises à jour
>> sans recompiler toutes les applications qui les utilisent, dans le cas
>> d'un bugfix mineur notament.
>
> Cet argument ne tient que si le "format intermédiaire" d'export peut
> être déployé dans une librairie dynamique, ce qui me semble
> extrêmement peu probable.
>
en effet. C'est ma mauvaise compréhension de export qui m'a orienté vers cet
argument. Mais maintenant c'est un peu plus clair...
Christophe Lephay
de news: 3e6f0372$0$254$626a...@news.free.fr...
En fait ça sonne assez comme du Pierre Dac :)
Chris
Herb Sutter
On 12 Mar 2003 11:13:45 +0100, Gabriel Dos Reis
<g...@integrable-solutions.net> wrote:
>Arnaud Meurgues <arn...@meurgues.non.fr.invalid> writes:
>>| Gabriel Dos Reis wrote:
>|
>| > Voici des *faits* :
>| > 1) Il n'y a pas longtemps, Herb nous disait très fort que son
>| > employeur est la seule compagnie à avoir dit plubliquement (à
>| > part évidemment EDG) qu'ils implenteraient « export. »
>
>| C'est amusant, parce que ça paraît contradictoire avec l'introduction :
>| "
>| There is no known announced plan to
>| support export in any other commercially available compiler product.
>| "
C'est vrai, ca, mais peut-etre je dois utiliser les mots plus specifiques.
Pour moi, "announced plan" == "in a specific release." (Si une compagnie me
disent qu'ils vont implenterer X mais ils ne disent pas _quand_, ce n'est
pas tres utile pour moi...) Quelle phrase peut-je utiliser en place de
"announced plan" pour assurer que le lecteur a le sens correct? Je veux dire
quelquechose en plus que seulement "stated intent" (qui est inutile).
NB: Comme j'ai ecrit dans le papier, Intel a pu avoir export en 7.x (ils ont
la facilite parce que Intel 7.x utilise EDG 3.x), mais ils n'ont pas fait,
ils l'ont suppresse. Je ne sais pas si Intel va supporter export, mais Intel
aussi as aucun plan annonce pour supporter export dans une version
specifique. (NB, Intel est un "sponsor" de ce papier.)
>De:
>http://groups.google.fr/groups?q=allintext:+Sutter+export+Microsoft&hl=fr&lr=lang_en&ie=UTF-8&as_qdr=all&selm=kessfugafqjkcq16sl0jt2sf76btrs5feh%404ax.com&rnum=1
>
>Je cite :
> Microsoft is the only vendor I know of, besides EDG and Comeau, who
> has publicly *committed* to implementing export.
C'est aussi vrai. Microsoft n'a pas annonce un plan pour implenterer export
a un temps / dans une version specifique, seulement qu'ils veulent devenir
completement conformant -- et avec 7.1 "Everett" (avril 2003), je pense que
c'est evident q'ils sont serieux; ils ont (finalement) fait beaucoup de
travail pour conformance, et ca avant que je suis arrive. Everett est >98%
conformant -- mais Everett n'implenteras pas trois choses majeurs: a)
exception-specifications; b) 2-phase lookup; et c) export.
Dans la prochaine version, "Whidbey" (2004), VC++ va implenterer (a),
peut-etre (b), mais pas (c) -- ce n'etait pas possible de implenterer export
avec qualite en Whidbey.
Herb
---
Herb Sutter (www.gotw.ca)
Convener, ISO WG21 - Secretary, ANSI J16 (www.gotw.ca/iso)
Contributing editor, C/C++ Users Journal (www.gotw.ca/cuj)
C++ community program manager, Microsoft (www.gotw.ca/microsoft)
Herb Sutter
<g...@integrable-solutions.net> wrote:
>Voici des *faits* :
>
> 1) Il n'y a pas longtemps, Herb nous disait très fort que son
> employeur est la seule compagnie à avoir dit plubliquement (à
> part évidemment EDG) qu'ils implenteraient « export. »
C'est vrai. (Vois l'autre reponse que j'ai ecrit.)
> 2) Entre temps Herb écrit des articles pour nous expliquer que
> « export » est Mal
C'est aussi vrai. C'etait mon opinion avant que j'etais devenu employe de
Microsoft. :-)
> 3) Un an après le « public commitment », Herb nous explique qu'il
> faut enlever « export ».
Je ne suis pas le seul. NB aussi: J'ai ecrit ce papier il ya 10 mois (avec
l'assistance de EDG et autres); je ne l'ai pas distribue a la comite parce
que Dinkumware et EDG m'ont demande si je peux s.v.p. laisser encore un peu
plus de temps passer pour experimentation parce qu'il y a maintenant
(finalement) une implenteration qu'on peut examiner -- et je l'ai fait.
>Il y a beaucoup d'exagération dans cet article.
Quels sont les exagerations? Je voudrai bien avoir l'opportunite de repondre
(mais en anglais :-/ pour etre sur que je suis accurat).
Jean-Marc Bourguet
> On 11 Mar 2003 17:09:39 +0100, Gabriel Dos Reis
> <g...@integrable-solutions.net> wrote:
> >Voici des *faits* :
> >
> > 1) Il n'y a pas longtemps, Herb nous disait très fort que son
> > employeur est la seule compagnie à avoir dit plubliquement (à
> > part évidemment EDG) qu'ils implenteraient « export. »
>
> C'est vrai. (Vois l'autre reponse que j'ai ecrit.)
>
> > 2) Entre temps Herb écrit des articles pour nous expliquer que
> > « export » est Mal
>
> C'est aussi vrai. C'etait mon opinion avant que j'etais devenu employe de
> Microsoft. :-)
>
> > 3) Un an après le « public commitment », Herb nous explique qu'il
> > faut enlever « export ».
>
> Je ne suis pas le seul. NB aussi: J'ai ecrit ce papier il ya 10 mois (avec
> l'assistance de EDG et autres); je ne l'ai pas distribue a la comite parce
> que Dinkumware et EDG m'ont demande si je peux s.v.p. laisser encore un peu
> plus de temps passer pour experimentation parce qu'il y a maintenant
> (finalement) une implenteration qu'on peut examiner -- et je l'ai fait.
>
> >Il y a beaucoup d'exagération dans cet article.
>
> Quels sont les exagerations? Je voudrai bien avoir l'opportunite de repondre
> (mais en anglais :-/ pour etre sur que je suis accurat).
Here is a quick summary of what I wrote in previous messages.
I've commented on the user's perspective, not the compiler implementer
one nor the langage designer one. I bough Comeau's compiler when it
was released to experiment because there was too much confusion on
what was said on export in clc++m and wanted to make sure of the
reality. I've never used it on a "real live" projects but did some
experiments so check if it provided what I expected from it. Short
answer: it did.
export does not bring what some expected. I did not had -- and never
had, even before the discussion in clc++m -- the deceived
expectations usually cited
- possibility of hiding the source -- its of none interest for me
and I think encryption is at least as good as a solution and more
general
- some other expectations -- like beeing able to put exported
templates in a dynamic library -- showing IMHO an important lack
of understanding of the template model of C++
So I do not have a "rejected lover attitude" due to these points.
export do bring some things you deny in your article (and these where
the points I expected), at least when implemented in conjunction with
what D. Vandevoorde call the iterated model of instantiations (that
should be the same with the queried model but probably not the greedy
one):
- a reduction of dependancies
- better compilation times in some cases.
For the latter point, I can build examples showing a ratio as small as
wanted between the build time with export and without export (I did so
with the ratio being 1/5 and with export I did not used precompiled
header while without export I did).
More significantly, people here known that I don't use template very
much in production code and most of my uses are implementation
artefacts (containers, smart pointer and such kind of things). Once
there was a project where I wanted to use them for application level
code (the project was cancelled, but that's another story). I reused
the significant caracteristics of this projets and measured the effect
of export. With two translation units using an instantiation it was a
win of 25% when building from scratch, 30% when rebuilding after
having modified a type used in a template parameter and of 40% when
rebuilding after having modified the template implementation. Anew,
these times where measured using precompiled headers when not using
export and not using them for export. In production code the
proportion would be obviously less because there would be more non
template code but the reduction in header size not would be
significantly less and there would be more than two translation units
using one instantiation.
The two factors making a improvements are the number of translation
units using an instantiation and the reduction of header size due to
export in these translation units, so if the reduction in header size
is enough just adding new translation units reduce the ratio. Having
just one translation unit using an instantiation is rare in my code,
but I've no idea of what would be a typical reduction in header size.
For the SL, this is probably small because excepted for IOStreams and
locale, most of the implementation would be usually put inline but you
saw above the measure for at least one application.
You state that export need modification in the build system. I reused
the makefiles I use with gcc, modified them to build with como without
export and then export worked without further modification (excepted
to add the files providing the template implementations to the list of
files to be build and linked). I tried to push then to miss some
dependancies (using libraries and so on) but did not succeed, so there
may be bugs but probably no conceptual problems. With those
makefiles, after modifying a template implementation, at most one file
per instantiation is rebuild.
I think your article exagerate cases where export would give
surprising results. The cases I've seen described involved overloaded
functions with the set of visible overloaded functions beeing
different at different places and implicit conversions. You don't
need export to get surprising results in these conditions.
I don't undestand the issues you have with the ODR. As far as I know,
with or without export, if I break the ODR, I get what I desserve.
The only thing new with export is that some violations are now
detected by the compiler. That's good news for me.
I don't undestand the issues you have with unnamed namespace. For me,
unnamed namespace is a way to give sensible names while beeing sure
not to break the ODR. The only way I think a function in an unnamed
namespace is used in an instantiation, is the use of the two-phases
lookup. That mean that the template writer perhaps has to take some
precautions but I fail to see a surprising result which he can not
prevent.
I liked very much the point "It enables a code organization
style. (Whether the style is desirable can be debated.)" The first
question on templates from a new person in this newsgroup has usually
"you needed exported templates but most probably you don't have a
compiler supporting them. The alternate way is ..." and the reaction
is one of deception and uncredulity. You may not consider that the
style is desirable, but it is desired.
Yours,
Serge Smeesters
>
> http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford
Merci, ça m'intéresse énormément !
> Le papier "Why We Can't Afford Export" est « intéressant. ».
En effet !
Je ne suis pas encore un expert en la matière. Je n'ai pas encore
eu l'occasion d'utiliser 'export'. Par contre, j'utilise beaucoup
les templates dans mes programmes et je réfléchis beaucoup à
propos de la "méta-programmation". Je n'ai pas encore pratiqué
Java ou C# mais je suis très attentif à comprendre l'évolution du
processus de "régression". Je ne suis pas sûr du terme, j'entends
par-là, tout processus qui transforme la forme d'un
"algorithme"(ce mot est peut-être réducteur ici...) de sorte à
optimiser son "traitement"(exécution).
En parallèle à cela, il me semble devoir considérer les aspects
"humains". Ces aspects sont d'ordre philosophique et politique
mais également psychologique et "ergonomique"("élégance du
code"?).
Aujourd'hui, je suis très sensible aux revendications de la
communauté des logiciels libre (projet FSF/GNU). Et je ne suis
pas le seul, ainsi, à ressentir une certaine confrontation.
Aussi, je suis facilement tenté (je suis faible;) d'observer de
nombreux faits(les plus divers) selon ces enjeux politiques et
philosophiques.
Revenons à la "régression". Hormis ses qualités opérationnelles,
il faut parfois considérer la visibilité des algorithmes à
travers les différentes "étapes"(s'il y en a de bien distinctes)
de la "régression" et les possibilités en terme de modularité.
Maintenant, à propos de 'export' du C++, je ne sais pas encore
dire grand chose mais j'ai l'impression que les principes de
"régression" qui émanent du C++ (compilation (ici surtout) /
édition des liens ("ici un peu" ou "discuté") / exécution ("pas
prévu" ou "le moins possible") implique (concernant les templates
avec 'export') une rémanence lexicale qui peu contrarie certains
besoins concernant la visibilité des algorithmes...
Je suis près à accepter qu'un langage et une architecture
puissent avoir l'ambition de contenter au mieux ces besoins mais
je trouverais dommage que la recherche (fondamental et appliqué)
s'interdise une voie pouvant contrarier ces même besoins non
inhérents au domaine de la "régression logarithmique".
J'espère ne pas avoir dis trop de connerie.
Je continue à réfléchir à tout ceci...
Serge.
Michel Michaud
message de news: m38yvlg...@uniton.integrable-solutions.net...
> "Michel Michaud" <michel....@cstjean.qc.ca> writes:
> | D'un autre côté, Sutter travaille maintenant pour une
> | compagnie qui économiserait en n'implantant pas export ?
> Je crois qu'on cherche à faire un procès d'intentions...
>
> Je ne cherche pas à faire des procès d'intention.
L'idéal est de demander directement à Herb... C'est fait semble-t-
il...
[...]
> | Ce qui est dit dans l'article n'est pas absurde
>
> As-tu des preuves ?
Euh, ça prendrait le contraire non ? (des preuves de l'absurdité)
Je vois que certains passages peuvent être critiqués (et c'est ce
que certains font sur ce forum), mais ça n'en reste pas moins des
commentaires valables même si ce ne sont pas les seuls qu'on peut
émettre. Je suis surpris : je ne vois pas de discussions sur ce
document sur clc++m...
> | et ceux qui ont
> | travaillé fort pour avoir un export fonctionnel seraient les
> | plus grands perdants si export était banni.
>
> Si seulement cela était vrai.
Ah ? Qui perdrait vraiment quelque chose ? (considérant que, pour
la plupart des gens, export n'existe pas dans leur quotidien)
(Je vois aussi les membres du comité qui ont passé du temps
là-dessus).
[...]
> C'est un peu comme si quelqu'un te dit : C++ est complexe donc il
> est inutilisable.
C'est pas le cas ? ;-)
Personnellement je crois que j'aimerais qu'il existe quelque chose
comme export, mais plus proche de ce que les gens veulent vraiment,
tout en ayant de problèmes et de complexité (la quadrature du
cercle peut-être !).
Si on peut améliorer export, il faut le garder. Si l'enlever permet
de penser ajouter quelque chose de mieux, alors c'est moins clair...
Jean-Marc Bourguet
> Personnellement je crois que j'aimerais qu'il existe quelque chose
> comme export, mais plus proche de ce que les gens veulent vraiment,
C'est quoi ce que les gens veulent vraiment? Personnellement, je
constate que j'ai ce que j'attendais (réduction des dépendances et
diminution du temps de compilation dans les cas favorables).
A part le fait de cacher les sources (ce qui n'impacte pas tant de
gens que ça), les seules autres attentes que j'ai vue exprimées sont
irréalisables avec le modèle de généricité du C++ (ne pouvant pas
gérer les spécialisations par exemple).
> tout en ayant de problèmes et de complexité (la quadrature du cercle
> peut-être !).
Complexité pour qui? Ceux qui définissent le langage? Ceux qui
implémentent un compilateur? Ceux qui écrivent des bibliothèques?
Ceux qui se contentent d'utiliser?
Pour les utilisateurs de base (ceux qui se contente d'utiliser des
templates écrits par d'autres ou par eux-même mais n'en fournissent
pas), je n'ai pas encore vu de problèmes importants dus à des causes
qui n'en produiraient pas ailleurs.
Pour ceux qui font des bibliothèques, il me semble que les techniques
qu'ils doivent employé pour que leur template avec export soient
robustes sont exactement les mêmes que sans. Faire attention à ce qui
est un nom dépendant et ce qui ne l'est pas et connaître la recherche
des noms en deux phases. Ses implications sont peut-être plus
communes avec export, mais pas fondamentalement différente.
> Si on peut améliorer export, il faut le garder. Si l'enlever permet
> de penser ajouter quelque chose de mieux, alors c'est moins clair...
Si le document était titré "Un remplacement à export", je crois que
les réactions seraient un peu différentes. Tel que je le lis, c'est
un appel à le supprimer sans proposition de remplacement. C'est
relativement normal car j'ai l'impression que sans changer en
profondeur le modèle de généricité -- celui-là même qui permet la
méta-programmation -- on tombera dans les même limitations.
A+
Michel Michaud
ddpq4b...@news.bourguet.org...
> "Michel Michaud" <michel....@cstjean.qc.ca> writes:
>
> > Personnellement je crois que j'aimerais qu'il existe quelque chose
> > comme export, mais plus proche de ce que les gens veulent
> > vraiment,
>
> C'est quoi ce que les gens veulent vraiment? Personnellement, je
> constate que j'ai ce que j'attendais (réduction des dépendances et
> diminution du temps de compilation dans les cas favorables).
Mais moins que ce « qu'on » pouvait espérer.
Idéalement, j'imagine que ce que les gens espèraient c'est de ne pas
avoir besoin d'accéder à la définition d'une classe (ou fonction)
template lors de la compilation des fichiers qui l'utilise. Et
d'avoir à « compiler » une seule fois le fichier d'implémentation.
L'éditeur de liens aurait beaucoup de travail, c'est sûr. Permettre
de développer indépendamment l'interface de l'implémentation, comme
pour la compilation séparée qui existe depuis toujours, est tellement
important pour certains, qu'attendre lors de l'édition des liens est
sans implication...
Je ne dis pas que c'est possible. Par contre, je crois que beaucoup
de personnnes n'avaient pas les connaissances nécessaires pour
savoir que ce ne serait pas comme ça avec export.
> > tout en ayant de problèmes et de complexité (la quadrature du
> > cercle peut-être !).
>
> Complexité pour qui? Ceux qui définissent le langage? Ceux qui
> implémentent un compilateur? Ceux qui écrivent des bibliothèques?
> Ceux qui se contentent d'utiliser?
Pour tout le monde idéalement, mais d'abord pour les utilisateurs.
Si export ajoute des problèmes particuliers, et Herb semble dire que
c'est bien clair, ça complique l'utilisation. Est-ce qu'il pourrait
y avoir moins de ces problèmes ? Je ne sais pas...
[...]
> Si le document était titré "Un remplacement à export", je crois que
Il fallait bien un titre choc :-) Mais tu as raison, le fait de dire
qu'on ne peut pas se payer (afford) export, semble dire que c'est
très bon, mais pas facile à avoir...
> les réactions seraient un peu différentes. Tel que je le lis, c'est
> un appel à le supprimer sans proposition de remplacement. C'est
Quand même dans 2.7 : Export's existence in the standard prevents us
from adopting something better in the future [....]. Alors on peut
comprendre.
> relativement normal car j'ai l'impression que sans changer en
> profondeur le modèle de généricité -- celui-là même qui permet la
> méta-programmation -- on tombera dans les même limitations.
Moi, je ne sais pas. Tu es sûr ? Je pense que si export reste,
personne ne perdra du temps à trouver un nouveau principe qui ne
pourrait être ajouter à C++ puisque export est déjà là...
Ceci dit, je ne suis pas assez expert de export (loin de là !), pour
dire s'il faut le retirer ou s'il suffira. Mais j'ai l'habitude de
me fier à des experts : Herb Sutter et Thomas Plum, ça me paraît
pas si mal...
Christophe Lephay
message de news: b4pqts$9h9$1...@ail.sri.ucl.ac.be...
> besoins concernant la visibilité des algorithmes...
> Je suis près à accepter qu'un langage et une architecture
> puissent avoir l'ambition de contenter au mieux ces besoins mais
> je trouverais dommage que la recherche (fondamental et appliqué)
> s'interdise une voie pouvant contrarier ces même besoins non
> inhérents au domaine de la "régression logarithmique".
>
> J'espère ne pas avoir dis trop de connerie.
C'est dur à dire. Essaies donc de dire les choses avec des mots plus simples
lol ;)
Chris
Jean-Marc Bourguet
> "Jean-Marc Bourguet" <j...@bourguet.org> a écrit dans le message de news:
> ddpq4b...@news.bourguet.org...
> > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
> >
> > > Personnellement je crois que j'aimerais qu'il existe quelque chose
> > > comme export, mais plus proche de ce que les gens veulent
> > > vraiment,
> >
> > C'est quoi ce que les gens veulent vraiment? Personnellement, je
> > constate que j'ai ce que j'attendais (réduction des dépendances et
> > diminution du temps de compilation dans les cas favorables).
>
> Mais moins que ce « qu'on » pouvait espérer.
>
> Idéalement, j'imagine que ce que les gens espèraient c'est de ne pas
> avoir besoin d'accéder à la définition d'une classe (ou fonction)
> template lors de la compilation des fichiers qui l'utilise. Et
> d'avoir à « compiler » une seule fois le fichier d'implémentation.
>
> L'éditeur de liens aurait beaucoup de travail, c'est sûr. Permettre
> de développer indépendamment l'interface de l'implémentation, comme
> pour la compilation séparée qui existe depuis toujours, est tellement
> important pour certains, qu'attendre lors de l'édition des liens est
> sans implication...
>
> Je ne dis pas que c'est possible. Par contre, je crois que beaucoup
> de personnnes n'avaient pas les connaissances nécessaires pour
> savoir que ce ne serait pas comme ça avec export.
Voila ce qui se passe avec export.
// f.hxx
export template <typename T> f();
// f.cxx
#include "f.hxx"
export template <typename T> f() {
}
// g.hxx
void g();
// g.cxx
#include "f.hxx"
void g() {
f<int>();
}
// main.cxx
#include "f.hxx"
int main() {
f<int>();
}
como -c g.cxx
// n'accede pas a f.cxx
como -c main.cxx
// n'accede pas a f.cxx
como -c f.cxx
como -o test main.o g.o f.o
// recompile g.cxx en instantiant f<int>() donc en accedant a f.cxx
edit g.cxx
como -c g.cxx
// instantie f<int>() donc accede a f.cxx
como -o test main.o g.o f.o
// ne recompile rien car l'instantiation existe
edit main.cxx
como -c main.cxx
// n'accede pas a f.cxx
como -o test main.o g.o f.o
// ne recompile rien car l'instantiation existe
edit f.cxx
como -c f.cxx
como -o test main.o g.o f.o
// recompile g.cxx en instantiant f<int>() donc en accedant a f.cxx
Quelles sont les differences avec ce que tu demandes?
* Plutot que d'utiliser une version "compilee" des templates de
f.cxx, on accede au texte? Plutot que d'utiliser une version
"compilee" du contexte d'instantiation dans g.cxx on accede a son
texte pour le retrouver et permette l'instantiation? Ce n'est en
rien une consequence d'export mais un choix d'implementation et
j'ai l'impression que reutiliser les techniques permettant les
en-tetes precompiles permettraient de s'affranchir de ces
contraintes sans trop de problemes. Je ne suis pas sur que ce
soit utile.
* On a en plus une "optimisation" qui evite de devoir recompiler un
fichier au moment de l'edition de liens si on sait qu'il doit
fournir des instantiations? Je ne vois pas de probleme avec ca,
mais si on veut l'eviter c'est trivial.
> > > tout en ayant de problèmes et de complexité (la quadrature du
> > > cercle peut-être !).
> >
> > Complexité pour qui? Ceux qui définissent le langage? Ceux qui
> > implémentent un compilateur? Ceux qui écrivent des bibliothèques?
> > Ceux qui se contentent d'utiliser?
>
> Pour tout le monde idéalement, mais d'abord pour les utilisateurs.
> Si export ajoute des problèmes particuliers, et Herb semble dire que
> c'est bien clair, ça complique l'utilisation.
Je ne trouve pas ca si clair que ca. Les seuls "surprises" que j'ai
reussit a avoir, c'est en combinant un abus de surcharge et de
conversion implicite. Et je n'ai pas besoin d'export pour avoir des
surprises dans ces cas la. Je manque peut-etre d'imagination, j'ai
peut-etre manque le message sur clc++m qui le donnait quand j'ai
verifie dans les archives, mais ma vision des choses est que les
difficultes sont dans les cas limites, donc pas pour l'utilisateur.
> Est-ce qu'il pourrait y avoir moins de ces problèmes ? Je ne sais
> pas...
>
> [...]
> > Si le document était titré "Un remplacement à export", je crois que
>
> Il fallait bien un titre choc :-) Mais tu as raison, le fait de dire
> qu'on ne peut pas se payer (afford) export, semble dire que c'est
> très bon, mais pas facile à avoir...
A lire l'article, l'impression qu'on a c'est que ca coute cher et que
ca n'apporte rien.
Tel qu'implemente actuellement, ca apporte ce que *moi* j'en
attendais, que l'article dit que ca n'apporte pas et sans certains
problemes que l'article dit qu'il y a. En plus j'ai l'impression que
l'article exagere certains l'importance d'autres problemes.
Quand je vois la precision sur les parties que je suis capable de
verifier, je me pose des questions sur la validite des commentaires
sur ce que je ne suis pas capable de verifier.
> > les réactions seraient un peu différentes. Tel que je le lis, c'est
> > un appel à le supprimer sans proposition de remplacement. C'est
>
> Quand même dans 2.7 : Export's existence in the standard prevents us
> from adopting something better in the future [....]. Alors on peut
> comprendre.
Mais j'aimerais voir au moins des pistes sur ce que ce "something
better" pourrait etre. Car j'ai l'impression qu'il y a eu intense
reflexion sur ce qui etait possible.
> > relativement normal car j'ai l'impression que sans changer en
> > profondeur le modèle de généricité -- celui-là même qui permet la
> > méta-programmation -- on tombera dans les même limitations.
>
> Moi, je ne sais pas. Tu es sûr ?
Dis moi les limitations qui te gene et je te dirais mon avis. Pour le
moment, a nouveau je n'ai vu que deux types de limitations:
- celles n'existant pas
- celles intrinseques au modele de genericite
Mais bon, ca ne fait que trois fois que j'en demande d'autres...
James Kanze
news:<c1nv6vkgacvtouk2t...@4ax.com>...
> Je m'excuse -- je parle (et ecris) le francais tres mal,
> On 12 Mar 2003 11:13:45 +0100, Gabriel Dos Reis
> <g...@integrable-solutions.net> wrote:
> >Arnaud Meurgues <arn...@meurgues.non.fr.invalid> writes:
> >>| Gabriel Dos Reis wrote:
> >| > Voici des *faits* :
> >| > 1) Il n'y a pas longtemps, Herb nous disait très fort que son
> >| > employeur est la seule compagnie à avoir dit plubliquement
> >| > (à part évidemment EDG) qu'ils implenteraient « export. »
> >| C'est amusant, parce que ça paraît contradictoire avec l'introduction :
> >| "
> >| There is no known announced plan to
> >| support export in any other commercially available compiler product.
> >| "
> C'est vrai, ca, mais peut-etre je dois utiliser les mots plus
> specifiques. Pour moi, "announced plan" == "in a specific release."
> (Si une compagnie me disent qu'ils vont implenterer X mais ils ne
> disent pas _quand_, ce n'est pas tres utile pour moi...) Quelle phrase
> peut-je utiliser en place de "announced plan" pour assurer que le
> lecteur a le sens correct? Je veux dire quelquechose en plus que
> seulement "stated intent" (qui est inutile).
L'utilité est toujours rélative. Tant qu'il ne l'ont pas réelement
implémenté, et que d'autres s'en sont servi (pour essuyer les plâtres),
ce ne m'est pas très utiles. Directement.
Dans la dernière version de g++ où je l'ai essayé, g++ n'avait pas
implémenter <locale>, au moins pas dans une façon utilisable. Ils
n'avaient pas non plus annoncé une version exacte ni une date où
l'implémentation y serait ; c'est leur politique, je crois, à ne pas
faire ce genre d'annonce (pour des raisons que je comprends bien). En ce
qui concerne <locale>, même, ils en ont dit bien moins que Microsoft par
rapport à export. N'empeche que je sais qu'il y a des gens qui
travaillent activement dessus, et que sans savoir exactement quand
(peut-être déjà, je n'ai pas essayé dernièrement), ils l'implémenteront.
Alors, des deux choses une : ou bien, Microsoft essayait à vendre du
vent en disant qu'ils comptaient implémenter « export », ou bien, il y a
des gens chez eux qui travaillent dessus, et qu'un jour ou l'autre, il
sortira.
> NB: Comme j'ai ecrit dans le papier, Intel a pu avoir export en 7.x
> (ils ont la facilite parce que Intel 7.x utilise EDG 3.x), mais ils
> n'ont pas fait, ils l'ont suppresse. Je ne sais pas si Intel va
> supporter export, mais Intel aussi as aucun plan annonce pour
> supporter export dans une version specifique. (NB, Intel est un
> "sponsor" de ce papier.)
C'est déjà plus intéressant. Je suppose, en tant que sponser, qu'ils
n'ont pas l'intention d'implémenter « export », bien qu'ils pourraient à
très peu de frais. La question alors reste pourquoi.
> >Je cite :
> > Microsoft is the only vendor I know of, besides EDG and Comeau, who
> > has publicly *committed* to implementing export.
> C'est aussi vrai. Microsoft n'a pas annonce un plan pour implenterer
> export a un temps / dans une version specifique, seulement qu'ils
> veulent devenir completement conformant -- et avec 7.1 "Everett"
> (avril 2003), je pense que c'est evident q'ils sont serieux; ils ont
> (finalement) fait beaucoup de travail pour conformance, et ca avant
> que je suis arrive. Everett est >98% conformant -- mais Everett
> n'implenteras pas trois choses majeurs: a) exception-specifications;
> b) 2-phase lookup; et c) export.
> Dans la prochaine version, "Whidbey" (2004), VC++ va implenterer (a),
> peut-etre (b), mais pas (c) -- ce n'etait pas possible de implenterer
> export avec qualite en Whidbey.
C'est sûr que la conformance ne vient pas d'un jour à l'autre, surtout
s'il n'a pas été une priorité avant. Et qu'on ne peut jamais aller
jusqu'au point à dire que c'est la seule priorité -- il faut constamment
prendre en compte les problèmes de la performance du compilateur, la
performance du code généré, et la compatibilité avec les versions
antérieur, aussi bien en ce qui concerne les sources que les
« binaires ». L'équation n'est pas simple -- même sans export, elle ne
serait pas simple -- et je suis franchement content de ne pas être un
vendeur de compilateurs C++. Aussi, je préfère ne pas avoir un
comportement à de l'avoir d'une façon qui ne marche pas -- le <locale>
de g++ 3.0 était pire que l'absense du <locale> dans 2.95.2. Personne ne
prétend que export est simple, et à mon avis, il est quand même
préférable qu'ils prenent le temps nécessaire à le faire correctement.
Gabriel Dos Reis
| Je m'excuse -- je parle (et ecris) le francais tres mal,
Ton français est meilleur que le mien et meilleur que mon anglais !
[...]
| >De:
| >http://groups.google.fr/groups?q=allintext:+Sutter+export+Microsoft&hl=fr&lr=lang_en&ie=UTF-8&as_qdr=all&selm=kessfugafqjkcq16sl0jt2sf76btrs5feh%404ax.com&rnum=1
| >
| >Je cite :
| > Microsoft is the only vendor I know of, besides EDG and Comeau, who
| > has publicly *committed* to implementing export.
|
| C'est aussi vrai. Microsoft n'a pas annonce un plan pour implenterer export
| a un temps / dans une version specifique, seulement qu'ils veulent devenir
| completement conformant
Pour moi, la phrase que j'ai citée veut dire que Microsoft s'est
engagé publiquement à implémenter "export". Je crois que c'est une
grande entreprise, suffisamment sérieuse, pour que son engagement
public soit soit pris au sérieux -- et de fait, je l'ai vraiment pris
au sérieux -- même s'il est vrai, comme tu le rappèles, que Microsoft
n'a pas donné une date précise, ni une version précise.
En tout cas, je suis de te voir répondre aux messages ici !
-- Gaby
Gabriel Dos Reis
| "Gabriel Dos Reis" <g...@integrable-solutions.net> a écrit dans le
| message de news: m38yvlg...@uniton.integrable-solutions.net...
| > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
| > | D'un autre côté, Sutter travaille maintenant pour une
| > | compagnie qui économiserait en n'implantant pas export ?
| > Je crois qu'on cherche à faire un procès d'intentions...
| >
| > Je ne cherche pas à faire des procès d'intention.
|
| L'idéal est de demander directement à Herb... C'est fait semble-t-
| il...
Herb et moi avions eu un bref échange de mail.
Mais c'est une très bonne chose qu'il puisse s'expliquer sur ce groupe.
Je ne sais pas qui le lui a demandé, mais c'était une bonne chose.
| [...]
|
| > | Ce qui est dit dans l'article n'est pas absurde
| >
| > As-tu des preuves ?
|
| Euh, ça prendrait le contraire non ? (des preuves de l'absurdité)
Non. Si tu dis que quelque chose n'est pas absurde, c'est que tu as
des éléments de preuve de le dire. Idem pour si tu avais dit que
c'était absurde.
| Je vois que certains passages peuvent être critiqués (et c'est ce
| que certains font sur ce forum), mais ça n'en reste pas moins des
| commentaires valables même si ce ne sont pas les seuls qu'on peut
| émettre. Je suis surpris : je ne vois pas de discussions sur ce
| document sur clc++m...
Ce qui donne aussi un intérête à clc++m. Je ne pense pas que les
disucssions sur fclc++ doivent être dec clônes de clc++m.
| > | et ceux qui ont
| > | travaillé fort pour avoir un export fonctionnel seraient les
| > | plus grands perdants si export était banni.
| >
| > Si seulement cela était vrai.
|
| Ah ? Qui perdrait vraiment quelque chose ? (considérant que, pour
| la plupart des gens, export n'existe pas dans leur quotidien)
Ceux qu'export ne décoit pas ?
| (Je vois aussi les membres du comité qui ont passé du temps
| là-dessus).
|
| [...]
| > C'est un peu comme si quelqu'un te dit : C++ est complexe donc il
| > est inutilisable.
|
| C'est pas le cas ? ;-)
|
| Personnellement je crois que j'aimerais qu'il existe quelque chose
| comme export, mais plus proche de ce que les gens veulent vraiment,
| tout en ayant de problèmes et de complexité (la quadrature du
| cercle peut-être !).
|
| Si on peut améliorer export, il faut le garder. Si l'enlever permet
| de penser ajouter quelque chose de mieux, alors c'est moins clair...
Comme je l'ai dit à Herb (en privé), la notion d'enlever quelque chose
de la norme sans le remplacer par une autre fonctionnalité meilleure,
ou sans des arguments techniques « fair » pourquoi la suppression
est une bonne chose pour l'utilisabilité du langage m'inconforte
énormément.
Si quelqu'un me dit qu'il a une alternative pour implémenter une
compilation séparée des template, mieux que ne le fait eactuellement
« export » et que la présence de ce dernier dans le langage devient
redondante ou incompatible, oui, je l'écouterai.
-- Gaby
Gabriel Dos Reis
| "Jean-Marc Bourguet" <j...@bourguet.org> a écrit dans le message de news:
| ddpq4b...@news.bourguet.org...
| > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
| >
| > > Personnellement je crois que j'aimerais qu'il existe quelque chose
| > > comme export, mais plus proche de ce que les gens veulent
| > > vraiment,
| >
| > C'est quoi ce que les gens veulent vraiment? Personnellement, je
| > constate que j'ai ce que j'attendais (réduction des dépendances et
| > diminution du temps de compilation dans les cas favorables).
|
| Mais moins que ce « qu'on » pouvait espérer.
Attention de quoi parle-tu de « ce que les gens veulent vraiment » ou
de ce « "qu'on" pouvait espérer ».
Les deux ne sont pas la même chose.
-- Gaby
Gabriel Dos Reis
[...]
| > les réactions seraient un peu différentes. Tel que je le lis, c'est
| > un appel à le supprimer sans proposition de remplacement. C'est
|
| Quand même dans 2.7 : Export's existence in the standard prevents us
| from adopting something better in the future [....]. Alors on peut
| comprendre.
Non. Ce que tu cites, est, pour moi, une profession de foi. En
particulier, il n'est pas démontré que l'existence de « export » est
uu frein à avoir quelque chose de mieux dans le futur. C'est juste une
assertion qui demande à être étayée. La répéter à l'infini n'en fera
pas une preuve.
| > relativement normal car j'ai l'impression que sans changer en
| > profondeur le modèle de généricité -- celui-là même qui permet la
| > méta-programmation -- on tombera dans les même limitations.
|
| Moi, je ne sais pas. Tu es sûr ? Je pense que si export reste,
| personne ne perdra du temps à trouver un nouveau principe qui ne
| pourrait être ajouter à C++ puisque export est déjà là...
Je crois que tu te trompes car je connais au moins trois personnes qui
réflechissent à comment améliorer la situation.
Je peux comprendre ta crainte. Sans preuve qu'il y a un réel frein, je
ne peux te suivre.
| Ceci dit, je ne suis pas assez expert de export (loin de là !), pour
| dire s'il faut le retirer ou s'il suffira. Mais j'ai l'habitude de
| me fier à des experts : Herb Sutter et Thomas Plum, ça me paraît
| pas si mal...
Et que se passe-t-il quand d'autres experts (et parmi lesquels des
implémenteurs et utilisateurs d'export) sont d'avis contraire ?
-- Gaby
James Kanze
news:<Mn6ca.962$wg5.1...@news20.bellglobal.com>...
> "Jean-Marc Bourguet" <j...@bourguet.org> a écrit dans le message de news:
> ddpq4b...@news.bourguet.org...
> > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
> > > Personnellement je crois que j'aimerais qu'il existe quelque chose
> > > comme export, mais plus proche de ce que les gens veulent
> > > vraiment,
> > C'est quoi ce que les gens veulent vraiment? Personnellement, je
> > constate que j'ai ce que j'attendais (réduction des dépendances et
> > diminution du temps de compilation dans les cas favorables).
> Mais moins que ce « qu'on » pouvait espérer.
On peut espérer beaucoup, sans s'attendre à l'avoir. En ce qui concerne
« ce que les gens veulent vraiment », il y a plusieurs positions
possibles : moi (et je ne me crois pas seul, même si je suis le plus
vocal), je veux surtout réduire des dépendances aux niveaux des
compilations. J'ai souvent travaillé sur des projets où il y avait
plusieurs milliers d'unités de compilation. Je peux te dire que si la
modification d'une implémentation en déclenche la récompilation de 80%
(comme c'est le cas sans export, avec des compilateurs aujourd'hui) ou
qu'il en déclenche la récompilation d'un (comme c'est apparamment le cas
avec l'implémentation d'« export » de Comeau/EDG), ça fait une
différence.
Mais mes attentes sont au moins en partie basées sur une connaissance de
la situation. Vue de l'extérieur, ce que je voudrais (et ce que je veux
réelement), c'est de pouvoir traiter une classe ou une fonction template
exactement comme n'importe quelle classe ou fonction. Je mets la
définition de la class ou la déclaration extern de la fonction dans un
fichier d'en-tête. Je mets les implémentations dans un ou plusieurs
fichiers de source. Je compile les sources, et je mets les objets qui en
résult dans une bibiliothèque. Dans le code client, j'inclus l'en-tête,
et lors de l'édition des liens, je spécifie la bibliothèque.
C'est faisable. Je sais le faire ; je sais que John Spicer (EDG) et Mike
Ball (Sun) savent le faire, parce qu'on en a discuté. La question est :
est-ce qu'on peut le faire à un prix acceptable -- la solution la plus
triviale, c'est simplement d'incorporer un image de la table de symboles
du compilateurs dans le fichier objet chaque fois qu'on a une
instantiation (implicite ou explicite) du template, et de récompiler
tous les instantiations à chaque édition de liens. Ça marche, mais ça
donne une taille inacceptable aux fichiers d'objet, et surtout un temps
d'édition de liens attroce.
> Idéalement, j'imagine que ce que les gens espèraient c'est de ne pas
> avoir besoin d'accéder à la définition d'une classe (ou fonction)
> template lors de la compilation des fichiers qui l'utilise. Et d'avoir
> à « compiler » une seule fois le fichier d'implémentation.
Si j'en juge par le nombre de questions qu'on en voit ici, j'imagine que
la plupart des gens ne posent pas de questions aussi profondes. Ils
veulent que les templates se comportent comme des classes et des
fonctions normales sur la surface. Ce que doit faire le compilateur
derrière leur dos pour le faire marcher ne leur concerne pas.
> L'éditeur de liens aurait beaucoup de travail, c'est sûr. Permettre de
> développer indépendamment l'interface de l'implémentation, comme pour
> la compilation séparée qui existe depuis toujours, est tellement
> important pour certains, qu'attendre lors de l'édition des liens est
> sans implication...
C'est la solution qu'utilisait CFront. Dans la pratique, ça ne marchait
pas trop mal ; mieux en tout cas que ce qu'on a actuellement. N'empeche
qu'il n'était pas sans problèmes :
- Le plus grand problème, c'est de définir la contexte
d'instantiation. CFront utilisait une heuristique selon les en-têtes
où étaient défini les types ou les valeurs d'instantiation. Ce qui
ne couvre pas tous les cas, et qui se prète mal à la normalisation,
vue la façon que les phases de compilation sont définie.
Dans une implémentation plus actuelle, tout le problème est là.
Comment communiquer assez d'informations concernantes la contexte
d'instantiation à l'éditeur de liens.
- L'autre problème de taille, c'est de savoir quand il fallait
compiler ces instantiations. Les récompiler à chaque édition de
liens est trop cher en termes de temps de build. Ici aussi, CFront
utilisait une heuristique basée sur les dates de modifications des
fichiers avec les déclarations et les définitions du template ainsi
que les fichiers avec les déclarations des types et des valeurs
d'instantiation. Le résultat, c'est qu'on récompilait prèsque
toujours beaucoup plus que nécessaire (avec en conséquence des temps
d'édition de lien très long), mais avec des cas où on ne récompilait
pas tout ce qu'il aurait fallu -- c'était connu qu'en cas d'une
erreur un peu bizarre à l'éxecution, la première chose à faire,
c'était de virer le répositoire pour régénérer toutes les
instantiations de nouveau.
> Je ne dis pas que c'est possible. Par contre, je crois que beaucoup de
> personnnes n'avaient pas les connaissances nécessaires pour savoir que
> ce ne serait pas comme ça avec export.
L'histoire de export est assez tordue. Mais je ne crois pas que les gens
qui ont insisté que quelque chose de ce genre soit présent (moi-même,
mais aussi Stroustrup et Koenig) étaient des naïfs, ni que les gens qui
l'ont défini (surtout John Spicer) voulait nous berner. Quand on (c-à-d
Stroustrup, Koenig et moi) a accepté export, on reconnaissaient bien
qu'il n'était pas parfait. En fait, on ne voulait pas export ; on
voulait que les templates se comportent d'une façon normalle et
intuitive sans export.
> > > tout en ayant de problèmes et de complexité (la quadrature du
> > > cercle peut-être !).
> > Complexité pour qui? Ceux qui définissent le langage? Ceux qui
> > implémentent un compilateur? Ceux qui écrivent des bibliothèques?
> > Ceux qui se contentent d'utiliser?
> Pour tout le monde idéalement, mais d'abord pour les utilisateurs. Si
> export ajoute des problèmes particuliers, et Herb semble dire que
> c'est bien clair, ça complique l'utilisation. Est-ce qu'il pourrait y
> avoir moins de ces problèmes ? Je ne sais pas...
> [...]
> > Si le document était titré "Un remplacement à export", je crois que
> Il fallait bien un titre choc :-) Mais tu as raison, le fait de dire
> qu'on ne peut pas se payer (afford) export, semble dire que c'est très
> bon, mais pas facile à avoir...
> > les réactions seraient un peu différentes. Tel que je le lis, c'est
> > un appel à le supprimer sans proposition de remplacement. C'est
> Quand même dans 2.7 : Export's existence in the standard prevents us
> from adopting something better in the future [....]. Alors on peut
> comprendre.
Comprendre quoi ?
Personnellement, je préfèrerais qu'il n'y avait pas export. Je
préfèrerais que les templates marchent « comme il faut », comme j'ai
décrit tout au debut. Comme si, grosso modo, tous les templates étaient
déclarés « export », sans que j'ai besoin de le spécifier. Mais
pratiquement, je crois que c'est trop tard. On ne peut pas dire pendant
5 ans qu'il faut mettre les implémentations dans les en-têtes pour dire
maintenant que c'est interdit de les y mettre.
> > relativement normal car j'ai l'impression que sans changer en
> > profondeur le modèle de généricité -- celui-là même qui permet la
> > méta-programmation -- on tombera dans les même limitations.
> Moi, je ne sais pas. Tu es sûr ? Je pense que si export reste,
> personne ne perdra du temps à trouver un nouveau principe qui ne
> pourrait être ajouter à C++ puisque export est déjà là...
> Ceci dit, je ne suis pas assez expert de export (loin de là !), pour
> dire s'il faut le retirer ou s'il suffira. Mais j'ai l'habitude de me
> fier à des experts : Herb Sutter et Thomas Plum, ça me paraît pas si
> mal...
Je ne sais pas combien d'expérience réele ils ont avec export. David
Vandervoorte, qui l'a implémenté, et Pete Becker et Jean-Marc, qui sont
les deux personnes à ma connaissance qui s'en sont servi, au moins à
titre expérimental, tous semblent être en desaccord avec ce que dit
Herb.
James Kanze
[...]
|> A lire l'article, l'impression qu'on a c'est que ca coute cher et
|> que ca n'apporte rien.
Surtout, à lire l'article, on a l'impression que Herb ne fait que
rapportait des avis des experts comme David Vandervoorde, etc., tandis
qu'en fait, ces experts sont tout à fait d'un autre avis.
Et à lire l'article, on a l'impression que des experts comme James
Kanze ne comprend rien d'export, parce qu'ils s'attendent à ce qu'on
n'a pas besoin de récompiler les instantiations en cas de modification
de l'implémentation du template, or que depuis tout le temps, je n'ai
jamais parlé que du problème de la récompilation du code client.
En passant, je travaillais sur un cas aujourd'hui où j'aurais bien été
content d'avoir export. J'ajoutais de la fonctionnalité à un template,
Plus précisement, j'ajoutais une fonction à une template de classe,
dont une instance était contenue dans une classe non templatée qui
servait à peu près partout. Évidemment, il n'y avait qu'une seule
source qui utilisait la nouvelle fonction. Mais du fait que ma classe
non-templatée incluait l'en-tête avec la définition du template
(obligatioire, puisqu'elle en avait un membre qui en était une
instance), et que l'entête de cette classe était inclue dans un
trentaine de fichiers, chaque fois que je modifiais l'implémentation
de cette nouvelle fonction, make récompilait une trentaine de
fichiers, tandis qu'un seul aurait suffit. D'après ce que j'ai compris
de ce que m'a dit David Vandervoorde, et selon les expériences de
Jean-Marc, je crois qu'avec Comeau (à la place de g++ 3.2.2), il n'en
aurait récompilé qu'un.
|> Tel qu'implemente actuellement, ca apporte ce que *moi* j'en
|> attendais, que l'article dit que ca n'apporte pas et sans certains
|> problemes que l'article dit qu'il y a. En plus j'ai l'impression
|> que l'article exagere certains l'importance d'autres problemes.
|> Quand je vois la precision sur les parties que je suis capable de
|> verifier, je me pose des questions sur la validite des
|> commentaires sur ce que je ne suis pas capable de verifier.
|> > > les réactions seraient un peu différentes. Tel que je le lis,
|> > > c'est un appel à le supprimer sans proposition de
|> > > remplacement. C'est
|> > Quand même dans 2.7 : Export's existence in the standard
|> > prevents us from adopting something better in the future
|> > [....]. Alors on peut comprendre.
|> Mais j'aimerais voir au moins des pistes sur ce que ce "something
|> better" pourrait etre. Car j'ai l'impression qu'il y a eu intense
|> reflexion sur ce qui etait possible.
Une chose qu'on pourrait certainement faire mieux : on laisse tomber
le mot clé export, on fait que tous les templates soient implicitement
« exportés », et on interdit toute cette duplication du code dans les
en-têtes.
--
James Kanze mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France Tel. +33 1 41 89 80 93
Herb Sutter
>> Quels sont les exagerations? Je voudrai bien avoir l'opportunite de repondre
>> (mais en anglais :-/ pour etre sur que je suis accurat).
>
>Here is a quick summary of what I wrote in previous messages.
Merci. :-)
>I've commented on the user's perspective, not the compiler implementer
>one nor the langage designer one. I bough Comeau's compiler when it
>was released to experiment because there was too much confusion on
>what was said on export in clc++m and wanted to make sure of the
>reality. I've never used it on a "real live" projects but did some
>experiments so check if it provided what I expected from it. Short
>answer: it did.
I also have never used it on a live project; I don't know anyone who has. In
part I think that is due to the main thing I did discover from my
experiments, namely the fragility of the feature in available
implementation(s).
My main experience with export (beyond a few small test samples) was my
extensive attempts last year to use Dinkumware's 4.0 export-enabled library
with EDG's 3.0.1 demo front-end and Comeau 4.3.0.1. I spent significant
effort on it over the course of several weeks, and with a lot of help from
Dinkumware in particular I finally managed to get Dinkumware's
export-enabled library to build correctly and reproducibly under EDG 3.0.1
-- that is, build it and get the same lib/et/ti/etc. files as Bill did --
but only after adopting Bill's advice that the only way he knew to get
reproducible builds was to throw away all the intermediate files every time,
which really defeats the purpose but could be chalked up to
version-1.0-itis.
Note that I was able eventually to get reproducible builds of DW 4.0 with
EDG 3.0.1 only; despite a lot of effort and support from Bill I never did
successfully get DW's lib to build with Comeau 4.3.0.1, and IIRC Bill agreed
that that configuration was less stable and fewer sites (only one or two,
including John Bento's who did DW's testing) had been able to reproduce it
correctly.
>export do bring some things you deny in your article (and these where
>the points I expected), at least when implemented in conjunction with
>what D. Vandevoorde call the iterated model of instantiations (that
>should be the same with the queried model but probably not the greedy
>one):
> - a reduction of dependancies
> - better compilation times in some cases.
Yes, I agree that such cases can be created.
Note: I too wanted (and tried) to do measurements of export vs. non-export
build speeds like this. The main reason I was forced to give up was the
(apparent) necessity of throwing away all the intermediate files and doing a
full build every time in order to be sure in general that the compilation
worked reproducibly. That is, I wanted to test incremental build
performance, but incremental build correctness was evidently unreliable, so
there was no point testing it. I don't know if this is any better in the
just-released EDG 3.1.
>You state that export need modification in the build system. I reused
>the makefiles I use with gcc, modified them to build with como without
>export and then export worked without further modification (excepted
>to add the files providing the template implementations to the list of
>files to be build and linked). I tried to push then to miss some
>dependancies (using libraries and so on) but did not succeed, so there
>may be bugs but probably no conceptual problems. With those
>makefiles, after modifying a template implementation, at most one file
>per instantiation is rebuild.
I'm glad you were successful in your tests, but export really does put new
constraints on the build environment. In EDG's implementation, using
libraries that use exported templates requires special mechanisms to compile
and link programs correctly. Specifically, in addition to the notes in the
paper, makefiles and other tools have to be able to deal with circular
dependencies, namely linkers that update their input (object) files. While
consulting at customer sites, I have had this issue raised to me a number of
times, not in the context of export but in other contexts where the customer
had steps in their build environment that updated the same step's input
files, and their build tools could not support such circular dependencies;
tools with such limitations are common, and we've spent lots of fun time
brainstorming ways to work around them and make the tools understand what's
going on (usually with compromises). Note that IBM until recently shipped a
C++ compiler product that required exactly such dependency support for a
feature similar to export, and the product was rejected in the marketplace
and no longer exists; one of the primary reasons users rejected it was its
difficulties with makefiles.
In related news, John Spicer pointed out to me in email this week that by
creating a new class of problems (i.e., program errors that span multiple
translation units, see example below), export requires a new class of
debugging tools. Paraphrasing his assessment: Today such tools do not exist
and are not available. What is more, we do not know how to design such
tools. Of course, if export ever became widely used, eventually such tools
would probably be developed out of necessity; but, until then, sophisticated
users are going to have serious problems.
>I think your article exagerate cases where export would give
>surprising results. The cases I've seen described involved overloaded
>functions with the set of visible overloaded functions beeing
>different at different places and implicit conversions. You don't
>need export to get surprising results in these conditions.
This certainly understates the new problems. Let me offer an example that
would be helpful, while also addressing your related question about:
>I don't undestand the issues you have with unnamed namespace.
Specifically, export is the only feature in C++ whereby, when compiling
translation unit A, the programmer can get errors on code in translation
unit B (actually, errors on code in an arbitrary number of other translation
units).
To illustrate, here is an example (courtesy of John Spicer) that
demonstrates interference between code in different unnamed namespaces in
multiple independent translation units.
//---file f1.h -------------------------------------------------------
export template <class T> void f1(T);
//---file f2.h -------------------------------------------------------
export template <class T1, class T2> void f2(T1, T2);
//---file f3.h -------------------------------------------------------
export template <class T1, class T2, class T3> void f3(T1, T2, T3);
//---file f1.c -------------------------------------------------------
//#include <stdio.h>
#include "f1.h"
#include "f2.h"
namespace {
struct B {};
void g1(B) { /*printf("g1(B)\n");*/ }
#ifdef ERR
template <class T1, class T2, class T3> void h(T1, T2, T3){}
#endif
}
template <class T> void f1(T t) {
B b;
f2(t, b);
}
//---file f2.c -------------------------------------------------------
//#include <stdio.h>
#include "f2.h"
#include "f3.h"
namespace {
struct C {};
void g1(C){/*printf("g1(C)\n");*/}
#ifdef ERR
template <class T1, class T2, class T3> void h(T1, T2, T3){}
#endif
}
template <class T1, class T2> void f2(T1 t1, T2 t2) {
C c;
f3(t1, t2, c);
}
//---file f3.c -------------------------------------------------------
#include "f3.h"
template <class T1, class T2, class T3> void f3(T1 t1, T2 t2, T3 t3) {
g1(t1);
g1(t2);
g1(t3);
#ifdef ERR
h(t1, t2, t3);
#endif
}
//---file t1.c -------------------------------------------------------
//#include <stdio.h>
#include "f1.h"
namespace {
struct A {};
void g1(A){/*printf("g1(A)\n");*/}
#ifdef ERR
template <class T1, class T2, class T3> void h(T1, T2, T3){}
#endif
}
int main() {
A a;
f1(a);
}
The output of compiling this program using EDG 3.0.1 with -DERR is, in part:
"f3.c", line 5: error: more than one instance of "h" matches the argument
list:
function template "<unnamed>::h(T1, T2, T3)" (from translation
unit "t1.c")
function template "<unnamed>::h(T1, T2, T3)" (from translation
unit "f1.c")
function template "<unnamed>::h(T1, T2, T3)" (from translation
unit "f2.c")
argument types are: (<unnamed>::A, <unnamed>::B, <unnamed>::C)
h(t1, t2, t3);
^
detected during:
instantiation of "void f3(T1, T2, T3) [with T1=<unnamed>::A,
T2=<unnamed>::B, T3=<unnamed>::C]"
compilation of secondary translation unit "f3.c"
This is certainly a surprising result to me. In general, it is highly
surprising to me (and certainly otherwise entirely without precedent in C++)
that when compiling translation unit A, the programmer can get errors on
code in translation unit B. (Note: Not "file B", but "translation unit B".)
>I don't undestand the issues you have with the ODR. As far as I know,
>with or without export, if I break the ODR, I get what I desserve.
>The only thing new with export is that some violations are now
>detected by the compiler. That's good news for me.
The main ODR issue isn't the runtime error you describe in the non-export
status quo today. The point here was that, with export, the compiler has to
do the ODR checking, not for the programmer's benefit, but just to prevent
crashing _the compiler itself_ because of the merging of internal data
structures. That may sound simple, but it's what took Daveed half a man-year
alone to implement. EDG reports that you have to do the work just to get a
working compiler.
Thanks for giving me the opportunity to provide some amplification on these
questions. Best wishes,
Jean-Marc Bourguet
> >I think your article exagerate cases where export would give
> >surprising results. The cases I've seen described involved
> >overloaded functions with the set of visible overloaded functions
> >beeing different at different places and implicit conversions. You
> >don't need export to get surprising results in these conditions.
>
> This certainly understates the new problems. Let me offer an example
> that would be helpful,
Well, the example involves overladed functions template functions with
the set of visible overloaded functions beeing different at different
places. OK, there is no implicit conversion but the additional use of
template is a complication of the same order.
> while also addressing your related question about:
>
> >I don't undestand the issues you have with unnamed namespace.
>
> Specifically, export is the only feature in C++ whereby, when
> compiling translation unit A, the programmer can get errors on code
> in translation unit B (actually, errors on code in an arbitrary
> number of other translation units).
I lack perhaps imagination, but the only way to prevent that while
still having separate compilation of template is to have constrained
templates, so no error had to be detected at instantiation time.
Even with the inclusion model, you can have ambiguities in the
instantiations that happen nowhere outside them because of the merging
findable of non qualified names in the context of template definition
and in the context of template instantiation. They are no harder to
trigger than with export, just the example may seem a little more
artificial. The following is a transformation of an example of C++
Templates showing overload ambiguities accross translation unit (in
the book, example is exporting f and putting the content of namespace
NS in another file in the global namespace).
class A {};
class B {};
class X {
public:
operator A() { return A(); }
operator B() { return B(); }
};
namespace NS {
void g(B) { }
void h() { g(X()); }
template <typename T>
void f(T x) {
g(x);
}
}
void g(A) { }
int main() {
g(X());
NS::f<X>(X());
}
And Comeau's compiler complains:
error: more than one instance of function "NS::g" matches
the argument list:
function "g(A)"
function "NS::g(B)"
argument types are: (X)
g(x);
^
detected during instantiation of "void NS::f(T) [with T=X]"
> To illustrate, here is an example (courtesy of John Spicer) that
> demonstrates interference between code in different unnamed
> namespaces in multiple independent translation units.
I see no special problem with unnamed namespaces. Name all of the
namespaces and you get the same problem. As soon as they have a name,
you can use the inclusion model to compile this, and you still get the
same problem. So no, I don't even think this is more surpising with
export. (The fact that is also happen with unnamed namespaces can be
a problem for the compiler writers)
> This is certainly a surprising result to me. In general, it is
> highly surprising to me (and certainly otherwise entirely without
> precedent in C++)
export is the only place where C++ attempt at separate compilation
(Everywhere else, it is carefully constructed to use independant
compilation masquarading as separate compilation with the help of the
preprocessor), so it is not surprising that there are effects which
are entirely without precedent in C++.
> that when compiling translation unit A, the programmer can get
> errors on code in translation unit B. (Note: Not "file B", but
> "translation unit B".)
It is not when compiling one translation unit or the other but when
producing instantiation units. And while doing this, as showed above
you can have errors resulting of the effective merge of context even
with the inclusion model.
> >I don't undestand the issues you have with the ODR. As far as I know,
> >with or without export, if I break the ODR, I get what I desserve.
> >The only thing new with export is that some violations are now
> >detected by the compiler. That's good news for me.
>
> The main ODR issue isn't the runtime error you describe in the
> non-export status quo today. The point here was that, with export,
> the compiler has to do the ODR checking, not for the programmer's
> benefit, but just to prevent crashing _the compiler itself_ because
> of the merging of internal data structures. That may sound simple,
> but it's what took Daveed half a man-year alone to implement. EDG
> reports that you have to do the work just to get a working compiler.
In a section titled "Difficult to use correctly", especially when
another section is title "(Prohibitively) Expensive to implement" I
was thinking you where stating user problems.
Jean-Marc Bourguet
> >export do bring some things you deny in your article (and these where
> >the points I expected), at least when implemented in conjunction with
> >what D. Vandevoorde call the iterated model of instantiations (that
> >should be the same with the queried model but probably not the greedy
> >one):
> > - a reduction of dependancies
> > - better compilation times in some cases.
>
> Yes, I agree that such cases can be created.
My main point was that in the first (and in fact only) example I used
which was not artificial but constructed to mimick a real live
application had an build time improvement (for full build, for
incremental build after a type which was a template parameter was
modified and for incremental build after the template definition was
modified).
Another point is that we where only writing about the reduction of
dependencies when instantiations where made in the compilation unit.
export also reduce them in the case where no instantiation of member
functions is used but a class somewhere has a class instantiation as a
data member. OK, in those case you can reduce the dependencies with
manual intervention to control where the definitions are saw and where
they are not, export does it for you.
> Note: I too wanted (and tried) to do measurements of export
> vs. non-export build speeds like this. The main reason I was forced
> to give up was the (apparent) necessity of throwing away all the
> intermediate files and doing a full build every time in order to be
> sure in general that the compilation worked reproducibly. That is, I
> wanted to test incremental build performance, but incremental build
> correctness was evidently unreliable, so there was no point testing
> it.
I found problems while playing with export, but none where related to
incremental build correctness. I was perhaps just lucky. But I want
to point out that I got better build time for incremental and for full
build (obviously if you can rely on incremental build, a better full
build does help only a little, excepted in pathological cases).
> I don't know if this is any better in the just-released EDG 3.1.
With the beta of Comeau 4.3.1, all the problems I reported where
fixed. But as I had none of unreliability, I can't say anything about
them.
> >You state that export need modification in the build system. I
> >reused the makefiles I use with gcc, modified them to build with
> >como without export and then export worked without further
> >modification (excepted to add the files providing the template
> >implementations to the list of files to be build and linked). I
> >tried to push then to miss some dependancies (using libraries and
> >so on) but did not succeed, so there may be bugs but probably no
> >conceptual problems. With those makefiles, after modifying a
> >template implementation, at most one file per instantiation is
> >rebuild.
>
> I'm glad you were successful in your tests, but export really does
> put new constraints on the build environment. In EDG's
> implementation, using libraries that use exported templates requires
> special mechanisms to compile and link programs
> correctly. Specifically, in addition to the notes in the paper,
> makefiles and other tools have to be able to deal with circular
> dependencies, namely linkers that update their input (object)
> files.
This is true for the iterated instantiation model even without export
so that's why I don't consider this as an export problem (but I agree
making export usefull with other instantiation models is probably a
more complicated matter). And not strictly so, with something like
the --one_instantiation_per_object mode of Comeau's compiler, it
should be possible to make the pre-linker work so that it doesn't
modify its source but only the template repository (in such case the
library tool would have to be aware of the template repository, but
that's not something particular nor of export nor of the iterated
model, Forte for instance which use the queried one already does
this).
The only make program (it's not a problem in the makefile but a
limitation on the make program) with which I had difficulties in such
cases was Rational's (well, now IBM's) clearmake. With it, the only
instantiation model which worked well with it at the time I was
involved was the greedy one; it does (did?) not handle very well the
fact that other tools can have a better view of dependancy than
itself. Not something you appreciate when you are sensitive to build
time nor when you use a compiler which does not directly support it
and you have to simulate it.
With the other make programs I've used, the only problem I'm aware of
in such cases is when an object which can be modified is a dependency
of several targets. If all the targets are able to modify it, you are
indeed in trouble, but I see no general solution which can be
obviously correct. If only one is, you have to make the other one
dependent on it.
Michel Michaud
message de news: m3r89a1...@uniton.integrable-solutions.net...
> Attention de quoi parle-tu de « ce que les gens veulent vraiment »
> ou de ce « "qu'on" pouvait espérer ».
>
> Les deux ne sont pas la même chose.
Je sais. Je sais surtout que je n'ai pas l'expérience de la chose.
Je n'ai pas non plus de sensation de manque en ne l'ayant pas. Je
ne peux donc pas faire mieux que convertir en « position » les divers
avis que j'ai pu lire sur les divers forums de discussion...
J'ai fait le mieux que je pouvais :-) Mon avis est que l'on ne doit
pas enlever export sauf si ça peut aider à mettre quelque chose de
« mieux » (et je ne dirai pas que je sais pour qui :-).
Michel Michaud
message de news: m3llzi1...@uniton.integrable-solutions.net...
> "Michel Michaud" <michel....@cstjean.qc.ca> writes:
> | Ceci dit, je ne suis pas assez expert de export (loin de là !),
> | pour
> | dire s'il faut le retirer ou s'il suffira. Mais j'ai l'habitude de
> | me fier à des experts : Herb Sutter et Thomas Plum, ça me paraît
> | pas si mal...
>
> Et que se passe-t-il quand d'autres experts (et parmi lesquels des
> implémenteurs et utilisateurs d'export) sont d'avis contraire ?
J'ai hâte de voir leurs avis. C'est pour ça que je suis étonné du
silence sur clc++m... Pour le moment, on a Herb qui parle ici !
Gabriel Dos Reis
| "Gabriel Dos Reis" <g...@integrable-solutions.net> a écrit dans le
| message de news: m3llzi1...@uniton.integrable-solutions.net...
| > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
| > | Ceci dit, je ne suis pas assez expert de export (loin de là !),
| > | pour
| > | dire s'il faut le retirer ou s'il suffira. Mais j'ai l'habitude de
| > | me fier à des experts : Herb Sutter et Thomas Plum, ça me paraît
| > | pas si mal...
| >
| > Et que se passe-t-il quand d'autres experts (et parmi lesquels des
| > implémenteurs et utilisateurs d'export) sont d'avis contraire ?
|
| J'ai hâte de voir leurs avis.
Dans ce cas tu as hâte d'assister à la prochaine réunion à Oxford... ;-)
| C'est pour ça que je suis étonné du silence sur clc++m...
Tout n'est pas forcément discuté sur clc++m -- je crois que c'est une
bonne chose :-)
-- Gaby
James Kanze
> "Gabriel Dos Reis" <g...@integrable-solutions.net> a écrit dans le
> message de news: m3llzi1...@uniton.integrable-solutions.net...
> > "Michel Michaud" <michel....@cstjean.qc.ca> writes:
> > | Ceci dit, je ne suis pas assez expert de export (loin de là !),
> > | pour dire s'il faut le retirer ou s'il suffira. Mais j'ai
> > | l'habitude de me fier à des experts : Herb Sutter et Thomas Plum,
> > | ça me paraît pas si mal...
> > Et que se passe-t-il quand d'autres experts (et parmi lesquels des
> > implémenteurs et utilisateurs d'export) sont d'avis contraire ?
> J'ai hâte de voir leurs avis. C'est pour ça que je suis étonné du
> silence sur clc++m... Pour le moment, on a Herb qui parle ici !
L'« article » en question fait partie de l'envoi au comité de
normalisation. Il faut s'attendre alors que la plupart des réactions
aient lieu dans la réunion du comité.
Quant aux experts, beaucoup ont déjà parlé en clc++m. La position de
Dinkumware, par exemple, est on ne peut plus clair -- on n'aurait
peut-être pas dû le faire, mais maintenant que c'est fait, il est hors
question de le supprimer. David Vandervoorde aussi a exprimé un
sentiment semblable. En plus, il a insisté sur le fait que s'il ne
supprime pas toutes les récompilations, il peut en supprimer une partie.
Tous les experts qui ont l'air d'avoir une expérience concrète semblent
s'accorder qu'il faut le garder.
Personnellement, je considère Gabi un expert en templates aussi, et il a
bien répondu ici.
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Arnaud Meurgues
> Et à lire l'article, on a l'impression que des experts comme James
> Kanze ne comprend rien d'export, parce qu'ils s'attendent à ce qu'on
> n'a pas besoin de récompiler les instantiations en cas de modification
> de l'implémentation du template, or que depuis tout le temps, je n'ai
> jamais parlé que du problème de la récompilation du code client.
Mais qui es-tu pour parler au nom de James Kanze ? ;-)
> Une chose qu'on pourrait certainement faire mieux : on laisse tomber
> le mot clé export, on fait que tous les templates soient implicitement
> « exportés », et on interdit toute cette duplication du code dans les
> en-têtes.
À vrai dire, je ne suis pas certain d'avoir bien compris les raisons qui
ont poussé à introduire "export". Si j'ai bien compris, le comportement
dont tu parles était ce que faisait CFront et c'est Borland qui a oeuvré
pour introduire le mot clef "export", prévoyant les difficultés
d'implémentation ?
Qui, a l'époque, s'est laissé convaincre et pourquoi ?
Arnaud
Arnaud Meurgues
> Je n'ai pas non plus de sensation de manque en ne l'ayant pas. Je
Moi, franchement, si. Pour des questions dépendance.
Quand j'étais "jeune" et que je programmais en C, je mettais du code
dans les .h parce que je n'avais pas bien compris l'importance de la
distinction interface/implémentation.
Ensuite, j'ai compris que mettre du code dans un .h était une hérésie,
en particulier parce qu'une modification de l'implémentation entrainait
la recompilation du code et aussi parce que tous les fichiers .o générés
à partir de .c incluant ces .h comportaient le même code que le linker
devait ensuite reconnaître comme étant identiques (je ne sais même pas
comment il fait).
Et maintenant, en C++, on voudrait me faire admettre qu'il est bon,
naturel et normal de mettre du code dans les .h ?!
Alors qu'au contraire, ma tendance serait de demander encore plus de
séparation entre interface et implémentation, par exemple en ne forçant
pas à mettre les membres privés dans le .h, et ne pas avoir besoin de PImpl.
Donc, non seulement export me manque, mais je trouve qu'il va de soi
(et, comme James, pense que ce devrait être le comportement normal de C++).
Tout ceci, bien sûr, en tant qu'utilisateur du langage. La difficulté
pour le implémenteurs ne m'intéresse pas (en fait, si, mais par curiosité).
> J'ai fait le mieux que je pouvais :-) Mon avis est que l'on ne doit
> pas enlever export sauf si ça peut aider à mettre quelque chose de
> « mieux » (et je ne dirai pas que je sais pour qui :-).
Oui. Je le partage d'une certaine façon. Mais je crois que j'aurais du
mal à accepter la disparition d'export sans la conditionner fortement à
un remplacement par quelque chose de mieux (et je vote [OUI] à la
proposition de James).
Arnaud
Gabriel Dos Reis
[...]
| > Une chose qu'on pourrait certainement faire mieux : on laisse tomber
| > le mot clé export, on fait que tous les templates soient implicitement
| > « exportés », et on interdit toute cette duplication du code dans les
| > en-têtes.
|
| À vrai dire, je ne suis pas certain d'avoir bien compris les raisons
| qui ont poussé à introduire "export". Si j'ai bien compris, le
| comportement dont tu parles était ce que faisait CFront et c'est
| Borland qui a oeuvré pour introduire le mot clef "export", prévoyant
| les difficultés d'implémentation ?
| Qui, a l'époque, s'est laissé convaincre et pourquoi ?
De ce que j'ai compris de l'histoire, c'est que CFront s'est
débrouillé pour implémenter la sémantique de « compilation séparée »
(avec des conventions de nommage, etc.). Borland a trouvé que cela
demandait moins de travail de demander à l'utilisateur d'inclure le
source partout où c'est nécessaire. G++ s'est évidemment engouffré
dans cette voie (de toute façon, à l'époque, il fallait être suiccidaire
pour utiliser g++ pour les templates). Des compilateurs comme Sun CC
(qui pourtant étaient basés sur CFront) ont aussi commencé à soutenir
le modèle Borland. À la fin, la sémantique initiale devenait
minoritaire dans les implémentations (si ce n'est pour disparaître).
L'existence du mot-clé export est le résultat d'un compromis : on
laisse le modèle Borland à condition de permettre la compilation
séparée de manière « standard ».
-- Gaby
Mickael Pointier
> Et maintenant, en C++, on voudrait me faire admettre qu'il est bon,
> naturel et normal de mettre du code dans les .h ?!
>
> Alors qu'au contraire, ma tendance serait de demander encore plus de
> séparation entre interface et implémentation, par exemple en ne
> forçant
> pas à mettre les membres privés dans le .h, et ne pas avoir besoin de
> PImpl.
>
> Donc, non seulement export me manque, mais je trouve qu'il va de soi
> (et, comme James, pense que ce devrait être le comportement normal de
> C++).
>
> Tout ceci, bien sûr, en tant qu'utilisateur du langage. La difficulté
> pour le implémenteurs ne m'intéresse pas (en fait, si, mais par
> curiosité).
J'en suis presque là moi aussi :)
De toute façon la majorité des langages actuels "souffrent" du même
symptome, c'est dire le fait qu'ils traitent des fichiers texte parsés
au moment de la compilation dans l'ordre. C'est ce qui fait qu'on est
obligé de déclarer des prototypes avant d'utiliser quelque chose, même
lorsque c'est dans le même fichier mais un peu plus bas :(
C'est aussi ce qui fait que des outils comme PC Lint sont capable de
trouver des problèmes que les compilateurs eux ne trouvent pas. (Les
Lint créent une base de donnée du projet en mémoire, et vérifie la
cohérence globale de la chose).
Après effectivement si ca veut dire qu'il faut supprimer la notion de
headers, rajouter des bases de données, etc... ca veut surement dire que
ca n'est plus le même langage.
Mike
Gabriel Dos Reis
| > [...]
| > Et maintenant, en C++, on voudrait me faire admettre qu'il est bon,
| > naturel et normal de mettre du code dans les .h ?!
| >
| > Alors qu'au contraire, ma tendance serait de demander encore plus de
| > séparation entre interface et implémentation, par exemple en ne
| > forçant
| > pas à mettre les membres privés dans le .h, et ne pas avoir besoin de
| > PImpl.
| >
| > Donc, non seulement export me manque, mais je trouve qu'il va de soi
| > (et, comme James, pense que ce devrait être le comportement normal de
| > C++).
| >
| > Tout ceci, bien sûr, en tant qu'utilisateur du langage. La difficulté
| > pour le implémenteurs ne m'intéresse pas (en fait, si, mais par
| > curiosité).
|
| J'en suis presque là moi aussi :)
|
| De toute façon la majorité des langages actuels "souffrent" du même
| symptome, c'est dire le fait qu'ils traitent des fichiers texte parsés
| au moment de la compilation dans l'ordre. C'est ce qui fait qu'on est
| obligé de déclarer des prototypes avant d'utiliser quelque chose, même
| lorsque c'est dans le même fichier mais un peu plus bas :(
Je ne suis pas certain de bien comprendre ce que tu veux dire.
Le problème de déclaration avant utilisation est orthogonal à la
question de compilation/interprétation.
[...]
| Après effectivement si ca veut dire qu'il faut supprimer la notion de
| headers, rajouter des bases de données, etc... ca veut surement dire que
| ca n'est plus le même langage.
Là non plus je ne comprends ce que tu veux dire. Qu'est-ce qu'un .o si
ce n'est une base de données ?
-- Gaby
Arnaud Meurgues
> (avec des conventions de nommage, etc.). Borland a trouvé que cela
> demandait moins de travail de demander à l'utilisateur d'inclure le
> source partout où c'est nécessaire.
Il n'avait pas tort.
> G++ s'est évidemment engouffré
> dans cette voie (de toute façon, à l'époque, il fallait être suiccidaire
> pour utiliser g++ pour les templates). Des compilateurs comme Sun CC
> (qui pourtant étaient basés sur CFront) ont aussi commencé à soutenir
> le modèle Borland.
Ok. C'était une cabale des implémenteurs qui ont baissé les bras devant
la difficulté, alors ? Mais les implémenteurs ont donc tant de poids
dans les décisions du comité ?
Et si c'est le cas, ne risque-t-on pas de voir arriver la même chose en
faveur de la suppression d'export ?
Arnaud
Arnaud Meurgues
> De toute façon la majorité des langages actuels "souffrent" du même
> symptome, c'est dire le fait qu'ils traitent des fichiers texte parsés
> au moment de la compilation dans l'ordre. C'est ce qui fait qu'on est
> obligé de déclarer des prototypes avant d'utiliser quelque chose, même
> lorsque c'est dans le même fichier mais un peu plus bas :(
Ce n'est pas le cas des "nouveaux" langages comme Java ou C#, il me
semble. Je suppose que ce n'était pas non plus le cas de smalltalk où la
résolution se fait en fait au runtime.
> Après effectivement si ca veut dire qu'il faut supprimer la notion de
> headers, rajouter des bases de données, etc... ca veut surement dire que
> ca n'est plus le même langage.
Là, je ne suis pas certain. La norme ne précise pas comment doit être
implémenté un compilateur et si un compilateur :
1- génère les erreurs demandées par la norme
2- produit un exécutable qui respecte la règle du "comme si"
alors il s'agit bien d'un compilateur C++, quelque soit son modèle de
compilation.
D'ailleurs, il me semble que VisualAge a un modèle de compilation du
type de celui dont tu parles, et il a la prétention d'être un
compilateur C++.
Arnaud
Arnaud Meurgues
> Là non plus je ne comprends ce que tu veux dire. Qu'est-ce qu'un .o si
> ce n'est une base de données ?
Je suppose qu'il voulait parler d'une base de donnée générale à un
programme et non locale à une unité de traduction.
Arnaud
Gabriel Dos Reis
[...]
| > G++ s'est évidemment engouffré
| > dans cette voie (de toute façon, à l'époque, il fallait être suiccidaire
| > pour utiliser g++ pour les templates). Des compilateurs comme Sun CC
| > (qui pourtant étaient basés sur CFront) ont aussi commencé à soutenir
| > le modèle Borland.
|
| Ok. C'était une cabale des implémenteurs qui ont baissé les bras
| devant la difficulté, alors ? Mais les implémenteurs ont donc tant de
| poids dans les décisions du comité ?
À quoi sert une norme si les implémenteurs refusent de l'implémenter ?
Et si un implémenteur connu et respecté pour son sérieux et son
professionalisme refuse, pour une raison X ou Y, d'implémenter une
disposition de la norme, que crois-tu que les autres vont faire ?
| Et si c'est le cas, ne risque-t-on pas de voir arriver la même chose
| en faveur de la suppression d'export ?
C'est un risque en effet. D'où l'utilité pour les utilisateurs de
faire entendre aussi leurs voies.
-- Gaby
Gabriel Dos Reis
Le modèle de compilation de C est un modèle parmi d'autres.
C'est un modèle très peu raffiné. Mais je ne vois pas très bien ce que
cela vient faire avec la notion de déclaration avant utilisation --
après tout dans K+R C, on pouvait utiliser une fonction sans avoir
une déclaration préalable.
-- Gaby
Christophe Lephay
> "Mickael Pointier" <mpoi...@eden-studios.fr> writes:
> | De toute façon la majorité des langages actuels "souffrent" du même
> | symptome, c'est dire le fait qu'ils traitent des fichiers texte parsés
> | au moment de la compilation dans l'ordre. C'est ce qui fait qu'on est
> | obligé de déclarer des prototypes avant d'utiliser quelque chose, même
> | lorsque c'est dans le même fichier mais un peu plus bas :(
>
> Je ne suis pas certain de bien comprendre ce que tu veux dire.
>
> Le problème de déclaration avant utilisation est orthogonal à la
> question de compilation/interprétation.
Comme illustration, on peut citer les membres des classes utilisables avant
(du point de vue de leur emplacement dans le fichier) leur déclaration...
Chris
Arnaud Meurgues
> Le modèle de compilation de C est un modèle parmi d'autres.
> C'est un modèle très peu raffiné. Mais je ne vois pas très bien ce que
> cela vient faire avec la notion de déclaration avant utilisation --
> après tout dans K+R C, on pouvait utiliser une fonction sans avoir
> une déclaration préalable.
Oui, mais à ma connaissance, non pas parce qu'il retardait la
connaissance de la fonction, mais parce qu'il lui donnait un type par
défaut qui pouvait très bien être erronné. Donc, cela introduisait une
faille dans le système de typage.
En revanche, si on envisage une précompilation qui range tous les
symbols dans une "BD", on peut alors gagner de ne pas avoir besoin de
forward déclaration tout en n'affaiblissant pas le typage.
On peut aussi choisir de faire de l'inférence de type, je suppose.
Mais j'extrapole les propos de Mickael et il vaudrait mieux qu'il
s'explique lui-même. Je ne traduis peut-être pas ses pensées.
Ce qui est possible, en tout cas, c'est d'imaginer qu'en gardant le
contrôle de type de C++, on puisse ce passer de forward déclaration. En
revanche, je ne suis pas assez pointu dans la construction de
compilateur pour déterminer si le coût à payer pour le compilateur est
acceptable ou non.
Arnaud
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
|
| > Le modèle de compilation de C est un modèle parmi d'autres.
| > C'est un modèle très peu raffiné. Mais je ne vois pas très bien ce que
| > cela vient faire avec la notion de déclaration avant utilisation --
| > après tout dans K+R C, on pouvait utiliser une fonction sans avoir
| > une déclaration préalable.
|
| Oui, mais à ma connaissance, non pas parce qu'il retardait la
| connaissance de la fonction, mais parce qu'il lui donnait un type par
| défaut qui pouvait très bien être erronné. Donc, cela introduisait une
| faille dans le système de typage.
C'est là où je veux en venir : c'est un problème de typage et non un
problème de compilation sáparée proprement dit.
| En revanche, si on envisage une précompilation qui range tous les
| symbols dans une "BD", on peut alors gagner de ne pas avoir besoin de
| forward déclaration tout en n'affaiblissant pas le typage.
Ah non ! La précompilation ne change rien à la déclaration antipicée :
tout ce que fait la précompilation c'est *d'optimiser* la compilation,
i.e. ne change pas le modèle de compilation.
| On peut aussi choisir de faire de l'inférence de type, je suppose.
Oui, ce qui est fait dans des langages « modernes » -- principalement
de la famille ML.
Mais là encore, l'inférence de type repose sur la déclaration avant
utilisation.
[...]
| Ce qui est possible, en tout cas, c'est d'imaginer qu'en gardant le
| contrôle de type de C++, on puisse ce passer de forward
| déclaration.
C'est contradictoire avec un typoage sûr.
-- Gaby
Arnaud Meurgues
> À quoi sert une norme si les implémenteurs refusent de l'implémenter ?
Effectivement. Il y avait donc unanimité chez les implémenteurs ?
> Et si un implémenteur connu et respecté pour son sérieux et son
> professionalisme refuse, pour une raison X ou Y, d'implémenter une
> disposition de la norme, que crois-tu que les autres vont faire ?
Dans le cas présent, un implémenteur connu et respecté pour son sérieux
et son professionalisme a implémenté export. Il est certain que ceci
devrait peser dans la balance en notre faveur. Mais si tous les autres
implémenteurs refusent, on retombe dans le problème précédent, non ?
> | Et si c'est le cas, ne risque-t-on pas de voir arriver la même chose
> | en faveur de la suppression d'export ?
> C'est un risque en effet. D'où l'utilité pour les utilisateurs de
> faire entendre aussi leurs voies.
J'ai du mal, je pense, à comprendre les rapports de forces qui existent
entre implémenteurs et utilisateurs. Ta phrase signifie-t-elle que si
les utilisateurs avaient fait entendre plus fort leur voix lors de la
normalisation, on aurait pu avoir export par défaut ? Ou implique-t-elle
que la situation d'aujourd'hui est assez différente (avec un
implémenteur ayant effeectivement implémenté la chose) pour que la voix
des utilisateurs soit suffisante là où elle ne l'était pas en 98 ?
Arnaud
Gabriel Dos Reis
Ici, il y a une subtilité : les utilisations des membres dans une
classe suivent la règle de réevaluation -- les définitions/déclarations
sont évaluées après la définition complète de la classe.
D'ailleurs cela ne marche pas très bien -- Michel Michaud a donné un
exemple assez récemment.
-- Gaby
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
|
| > À quoi sert une norme si les implémenteurs refusent de l'implémenter
| > ?
|
| Effectivement. Il y avait donc unanimité chez les implémenteurs ?
Je ne crois pas -- du moins si j compte Stroustrup et Koenig comme
implémenteurs ;-)
En réalité, c'est une question dont je ne connais pas la réponse
définitive.
| > Et si un implémenteur connu et respecté pour son sérieux et son
| > professionalisme refuse, pour une raison X ou Y, d'implémenter une
| > disposition de la norme, que crois-tu que les autres vont faire ?
|
| Dans le cas présent, un implémenteur connu et respecté pour son
| sérieux et son professionalisme a implémenté export. Il est certain
| que ceci devrait peser dans la balance en notre faveur.
C'est vrai. Cependant certains utilisent presque le même argument en
notre défaveur : ils les citent disant que cela demande beaucoup de
boulot :-)
| Mais si tous
| les autres implémenteurs refusent, on retombe dans le problème
| précédent, non ?
Sauf si les utilisateurs de l'implémentation actuelle en sont contents
et font pression sur les autres implémenteurs.
| > | Et si c'est le cas, ne risque-t-on pas de voir arriver la même chose
| > | en faveur de la suppression d'export ?
| > C'est un risque en effet. D'où l'utilité pour les utilisateurs de
| > faire entendre aussi leurs voies.
|
| J'ai du mal, je pense, à comprendre les rapports de forces qui
| existent entre implémenteurs et utilisateurs.
C'est un rapport qui n'est pas très net et tranché : après tout,
certainis implémenteurs prennent leurs utilisateurs importants
suffisamment au sérieux
| Ta phrase
| signifie-t-elle que si les utilisateurs avaient fait entendre plus
| fort leur voix lors de la normalisation, on aurait pu avoir export par
| défaut ?
Oui, c'est essentiellement ça.
-- Gaby
James Kanze
news:<3e7845b0$0$28770$626a...@news.free.fr>...
> À vrai dire, je ne suis pas certain d'avoir bien compris les raisons
> qui ont poussé à introduire "export". Si j'ai bien compris, le
> comportement dont tu parles était ce que faisait CFront et c'est
> Borland qui a oeuvré pour introduire le mot clef "export", prévoyant
> les difficultés d'implémentation ?
> Qui, a l'époque, s'est laissé convaincre et pourquoi ?
C'est une longue histoire, avec beaucoup de polémique, et beaucoup de
mésentente. Ce qu'on peut dire, c'est :
- L'implémentation de CFront était loin d'être parfaite. En
particulier, il résultait à des temps de build assez importants dans
certains cas. Aussi, son heuristique de determiner quand il fallait
« récompiler » une instantiation était loin d'être parfaite ;
c'était connu qu'en face d'un comportement « bizarre », la première
chose à faire, c'était d'éffacer les repertoires et régénérer tout.
- La norme a beaucoup changé la façon que fonctionne les templates.
L'implémentation CFront n'était pas très éloignée d'un macro -- le
compilateur ne regardait le code du template que lors de
l'instantiation. C-à-d qu'en cas d'erreur, on n'avait le premier
message d'erreur que lors de l'édition de liens.
La contexte d'instantiation de CFront se prétait mal à la
normalisation. Il était donc nécessaire de la rédéfinir. J'aurais
préféré une rédéfinition un peu plus près à ce qui existait déjà, au
moins dans les effets, mais dans les faits, je me suis pas rendu
compte du changement avant que la norme était votée -- je me suis
contenté des déclarations verbales que rien ne changeait dans la
pratique (ce qui est faut, mais en grande partie, les changements
étaient inévitables à cause de l'introduction des namespace).
- Certains implémenteurs, et non les moindres (John Spicer, de EDG, et
Mike Ball, de Sun) avaient exprimé leurs doutes sur la possibilité
de faire marcher le modèle CFront, au moins de façon « acceptable ».
(C-à-d sans un temps d'édition de liens inacceptables.)
Personnellement, je ne suis pas vraiment convaincu, mais c'est eux
qui en ont l'expérience avec la problèmatique, non moi.
Enfin, ce qui s'est passé, c'est qu'à la fin, le groupe qui s'occupait
des templates a sorti une proposition qui correspondait à peu près aux
templates d'aujourd'hui, sans export. Proposition qui a déclenché des
réactions de la part d'un certain nombre d'autres membres du comité,
dont moi-même, mais aussi Bjarne et Andy. Alors, on a ajouté export
comme un compromis ; c'était export, ou pas de separation du tout. Il ne
faut pas oublier non plus que ces discussions ont eu lieu à un époque où
tout le monde voulait avancer. C'était après le CD2, déjà, et personne
ne voulait être obligé à passer par un CD3.
--
James Kanze GABI Software mailto:ka...@gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Gabriel Dos Reis
[...]
| - La norme a beaucoup changé la façon que fonctionne les templates.
| L'implémentation CFront n'était pas très éloignée d'un macro
Les templates aujourd'hui ont-ils vraiment changé sur cet aspect ?
-- Gaby
Mickael Pointier
> Gabriel Dos Reis wrote:
>
>> Le modèle de compilation de C est un modèle parmi d'autres.
>> C'est un modèle très peu raffiné. Mais je ne vois pas très bien ce
>> que cela vient faire avec la notion de déclaration avant utilisation
>> -- après tout dans K+R C, on pouvait utiliser une fonction sans avoir
>> une déclaration préalable.
>
> Oui, mais à ma connaissance, non pas parce qu'il retardait la
> connaissance de la fonction, mais parce qu'il lui donnait un type par
> défaut qui pouvait très bien être erronné. Donc, cela introduisait une
> faille dans le système de typage.
>
> En revanche, si on envisage une précompilation qui range tous les
> symbols dans une "BD", on peut alors gagner de ne pas avoir besoin de
> forward déclaration tout en n'affaiblissant pas le typage.
>
> On peut aussi choisir de faire de l'inférence de type, je suppose.
>
> Mais j'extrapole les propos de Mickael et il vaudrait mieux qu'il
> s'explique lui-même. Je ne traduis peut-être pas ses pensées.
Tu extrapoles fort bien :)
Je suis désolé pour le coté "flou" de ce que j'ai pu dire.
En gros c'est venu d'une bête constatation. Quand je bosses sous
VisualStudios avec VisualAssist, et bien l'IDE il connait tous les types
que j'utilise et de m'indiquer où ils ont été définis, sans avoir à
compiler, ce que le compilateur lui même ne sais pas faire.
En gros moi je tappe pas beaucoup de code chaque jour, pourtant en
changeant une pôvre ligne dans un .H mal foutu, tout le projet est
recompilé. Si (disons en utilisant un IDE spécialisé et une base de
donnée prévue pour) on pouvait rentrer le code au fur et à mesure,
définir les types, et faire en sorte que l'on obtienne une vrai notion
d'interdépendance gérée à la base dans le le système de build on aurait
plus (moins ?) ces problèmes de micro-management de headers, de
prédéclarations et d'"include guards" et autres trucs du même style.
Le C++ à des cotés bien attrayant, mais je trouve que tout ce qui touche
au modèle de compilation, la visibilité externes des choses (devoir
mettre les détails d'implémentation privés dans la déclaration de la
classe pour connaitre la taille de l'objet), n'est pas vraiment ce qu'on
hérité de mieux du C :(
Mike
Gabriel Dos Reis
[...]
| Je suis désolé pour le coté "flou" de ce que j'ai pu dire.
| En gros c'est venu d'une bête constatation. Quand je bosses sous
| VisualStudios avec VisualAssist, et bien l'IDE il connait tous les types
| que j'utilise et de m'indiquer où ils ont été définis,
C'est parce que ton IDE a à tout instant une image complète de ton
code source *et* il n'essaye pas de traduire ton programme. C'est à
peu près la même différence qu'il y a entre « lire un roman et le
comprendre l'histoire qu'il raconte » (compilation) et « lire la
succession de mots qui composent le roman » (ce que fait l'IDE).
| sans avoir à
| compiler, ce que le compilateur lui même ne sais pas faire.
C'est parce que ton IDE ne fait pas de la compilation : il se contente
juste de déchiffrer les suites de caractères sans les comprendre ni
essayer de les corriger.
| En gros moi je tappe pas beaucoup de code chaque jour, pourtant en
| changeant une pôvre ligne dans un .H mal foutu, tout le projet est
| recompilé.
Ce que fait make tout les jours (et il ne comprend absolument rien au
C++), c'est juste uen gestionnaire de dépendance.
| Si (disons en utilisant un IDE spécialisé et une base de
| donnée prévue pour) on pouvait rentrer le code au fur et à mesure,
| définir les types, et faire en sorte que l'on obtienne une vrai notion
| d'interdépendance gérée à la base dans le le système de build on aurait
| plus (moins ?) ces problèmes de micro-management de headers, de
| prédéclarations et d'"include guards" et autres trucs du même style.
Encore une fois, tu confonds besoin typage et détails d'implémentation
d'un modèle de compilation. Comme je l'ai expliqué à Arnaud, c'est un
problème de typage et non celui du modèle de compilation.
-- Gaby
Arnaud Meurgues
> Ah non ! La précompilation ne change rien à la déclaration antipicée :
> tout ce que fait la précompilation c'est *d'optimiser* la compilation,
> i.e. ne change pas le modèle de compilation.
Oui. J'aurais dû mettre précompilation entre guillemets ou dire
"première passe de compilation", par exemple. Ce que je voulais dire,
c'est que la résolution pouvait être retardée après que tous les
éléments du programmes était connus.
> | Ce qui est possible, en tout cas, c'est d'imaginer qu'en gardant le
> | contrôle de type de C++, on puisse ce passer de forward
> | déclaration.
>
> C'est contradictoire avec un typoage sûr.
C'est-à-dire ?
Si on écrit par exemple :
double f(int i) { return g(i+2); }
double g(int d) { return 2*d; }
Sans définir au préalable g, en quoi cela est-il moins sûr que
double g(int);
double f(int i) { return g(i+2); }
double g(int d) { return 2*d; }
?
Arnaud
James Kanze
> Mickael Pointier wrote:
> > De toute façon la majorité des langages actuels "souffrent" du même
> > symptome, c'est dire le fait qu'ils traitent des fichiers texte
> > parsés au moment de la compilation dans l'ordre. C'est ce qui fait
> > qu'on est obligé de déclarer des prototypes avant d'utiliser quelque
> > chose, même lorsque c'est dans le même fichier mais un peu plus bas
> > :(
> Ce n'est pas le cas des "nouveaux" langages comme Java ou C#, il me
> semble. Je suppose que ce n'était pas non plus le cas de smalltalk où
> la résolution se fait en fait au runtime.
Il y avait deux philosophies : un typage dynamique lors de l'execution
(lisp, smalltalk), et un typage statique lors de la compilation (la
famille de Pascal). Le typage dynamique permet un prototypage plus
rapid ; le typage statique donne une sécurité accrue. Le typage
dynamique donne plus de liberté, mais impose d'avantage de
communications dans l'équipe -- à mon avis, il se prète mal à de gros
projets (mais il y a eu de gros projets en Smalltalk, et probablement en
Lisp). Le typage statique est plus contraignant, mais permet au
compilateur de trouver d'avantage d'erreurs -- la source fait partie de
la documentation (communication), partie qui est vérifiée par le
compilateur. Dans les langages les plus fortement typé statiquement
(Ada, la famille Modula), on a une section d'interface complètement
séparée de l'implémentation. Et autant que je sache, les déclarations de
l'interface (y compris les using) doivent précéder l'implémentation, que
ce soit l'implémentation client ou l'implémentation de l'interface même.
C'est évidemment une schématisation, et il existe des solutions
«@compromises ». Moi, par exemple, je trouve Java un peu schizophrène à
cet égard -- il n'arrive pas à savoir s'il veut avoir un typage statique
ou un typage dynamique. Donc, d'une côté, il faut bien déclarer les
fonctions, avec les types des paramètres, et ces déclarations doivent
être visible au compilateur (et à part les déclarations dans la classe
même, elles doivent précéder l'utilisation). Mais d'autre, non seulement
dérive tout de Object, mais on s'en sert énormement dans la
bibliothèque. Mais mon point de vue sur Java est sans doute conditionné
du fait que j'ai beaucoup travaillé sur de grands projets, et sur des
projets « critiques » -- environements où le typage statique a fait ces
preuves. D'après ce que je vois, Java a bien trouvé sa niche, dans les
applications de serveur Web. Des applications dont la taille est
typiquement plus grande que celle d'un script normal, mais nettement
plus petite que celle d'une application « stand-alone » classique.
En ce qui concerne C++ : c'est le résultat d'une évolution. Le langage
grand-père dont il dérive directement, c'est B, voire BCPL. Des langages
sans type, c-à-d effectivement à typage dynamique. Mais un typage non
vérifié ni par le compilateur ni à l'execution. Or, assez tôt dans
l'histoire de C, cette manque de vérification a été resentie comme un
défaut. Et vue que l'un des buts du langage (au moins dans les premiers
jours de C), c'était la performance lor de l'execution, le typage
dynamique (qui impose des vérifications lors de l'execution) a été
exclu. Mais le typage a été ajouté peu à peu, de manière ad hoc et en
fonction des besoins ; le passage de B (sans types, tout est un mot
machine) à C coïncide avec le passage à des machines à adressage
multiplet, et ça ne m'étonnerait pas du tout qu'une des motivations
soient de pouvoir exploiter les différents types que pourrait donc
adresser le hardware. Du coup, la notion de « module » et
d'«@interface@» manque, et la gestion des declarations au delà d'une
unité de compilation se fait par copie d'une partie de la source (les
fichiers d'en-tête).
Mais pour revenir au point de départ : les langages à typage strictement
statique ont prèsque tous, toujours, éxigé que les déclarations soient
visible au point de l'utilisation.
> > Après effectivement si ca veut dire qu'il faut supprimer la notion
> > de headers, rajouter des bases de données, etc... ca veut surement
> > dire que ca n'est plus le même langage.
> Là, je ne suis pas certain. La norme ne précise pas comment doit être
> implémenté un compilateur et si un compilateur :
> 1- génère les erreurs demandées par la norme
> 2- produit un exécutable qui respecte la règle du "comme si"
> alors il s'agit bien d'un compilateur C++, quelque soit son modèle de
> compilation.
En effet. Je me pose depuis longtemps la question pourquoi aucun
compilateur ne connaît le concepte de bibliothèque fermée. C-à-d que
j'aurais un fichier qui pour moi est un tout, et qui comporterait à la
fois les en-têtes (probablement précompilés) et les objets.
> D'ailleurs, il me semble que VisualAge a un modèle de compilation du
> type de celui dont tu parles, et il a la prétention d'être un
> compilateur C++.
Peut-être. Je ne sais pas quel est l'évolution de Visual Age
dernièrement. Je sais que quand on me l'a présenté la première fois, il
n'était pas conforme, parce que le compilateur voyait le contenu de tous
les en-têtes, que j'ai fait un #include ou non. Ce qui va à l'encontre
du typage statique, au moins dans le sens qu'il est entendu par Ada ou
Modula -- chaque « module » doit bien déclarer ce qu'elle importe. À
l'époque, les gens d'IBM ont réconnu que c'était une erreur, et ont
exprimé leur intention de le corriger. Mais depuis, je n'entends plus
parler du tout de Visual Age. (Il faut noter, en passant, que l'équipe
quie développait Visual Age à l'IBM vient du milieu Smalltalk, à typage
dynamique.)
James Kanze
news:<m3d6kns...@uniton.integrable-solutions.net>...
> ka...@gabi-soft.de (James Kanze) writes:
> [...]
Oui et non. La récherche en deux temps des symboles les en éloigne déjà
considérablement, puisqu'elle permet au compilateur de pouvoir faire une
bonne partie de la compilation avant l'instantiation. Et que la
signification des noms dépendants ne dépend pas de la contexte
d'instantiation.
Gabriel Dos Reis
| Gabriel Dos Reis <g...@integrable-solutions.net> wrote in message
| news:<m3d6kns...@uniton.integrable-solutions.net>...
| > ka...@gabi-soft.de (James Kanze) writes:
|
| > [...]
|
| > | - La norme a beaucoup changé la façon que fonctionne les templates.
| > | L'implémentation CFront n'était pas très éloignée d'un macro
|
| > Les templates aujourd'hui ont-ils vraiment changé sur cet aspect ?
|
| Oui et non. La récherche en deux temps des symboles les en éloigne déjà
| considérablement, puisqu'elle permet au compilateur de pouvoir faire une
| bonne partie de la compilation avant l'instantiation.
Ce qui est ennuyeux dans cet modèle schizophrène des templates, c'est
que d'un côté on fait une recherche de nom en deux et de
l'autre côté, on ne requiert pas que les erreurs les plus fragrantes
soient diagnostiqués lors du parsing du template -- ce qui leur donne
un goût très prononcé de macro.
-- Gaby
Gabriel Dos Reis
[...]
| > | Ce qui est possible, en tout cas, c'est d'imaginer qu'en gardant le
| > | contrôle de type de C++, on puisse ce passer de forward
| > | déclaration.
| > C'est contradictoire avec un typoage sûr.
|
| C'est-à-dire ?
|
| Si on écrit par exemple :
|
| double f(int i) { return g(i+2); }
| double g(int d) { return 2*d; }
De la manière que les tests ne montreront pas en général qu'un
programme est juste mais seulement qu'il est défaillant (Dijkstra), un
petit exemple peut juste montrer qu'un modèle est défaillant : pas
qu'il est juste.
Mainitenant, prenons
struct T {
/* plein de bonnes choses. */
};
doube f(T t) { return g(t) + 2; }
double g(int d) { return 2 * d; }
// ...
L'utilisation de g(0 dans f() est-elle une erreur ; est-ce la
défnition qui ne colle pas avec l'utilisation ?
-- Gaby
Gabriel Dos Reis
| Arnaud Meurgues <arn...@meurgues.non.fr.invalid> wrote in message
| news:<3e785ee0$0$28767$626a...@news.free.fr>...
| > Mickael Pointier wrote:
|
| > > De toute façon la majorité des langages actuels "souffrent" du même
| > > symptome, c'est dire le fait qu'ils traitent des fichiers texte
| > > parsés au moment de la compilation dans l'ordre. C'est ce qui fait
| > > qu'on est obligé de déclarer des prototypes avant d'utiliser quelque
| > > chose, même lorsque c'est dans le même fichier mais un peu plus bas
| > > :(
|
| > Ce n'est pas le cas des "nouveaux" langages comme Java ou C#, il me
| > semble. Je suppose que ce n'était pas non plus le cas de smalltalk où
| > la résolution se fait en fait au runtime.
|
| Il y avait deux philosophies : un typage dynamique lors de l'execution
| (lisp, smalltalk), et un typage statique lors de la compilation (la
| famille de Pascal). Le typage dynamique permet un prototypage plus
| rapid ; le typage statique donne une sécurité accrue. Le typage
| dynamique donne plus de liberté, mais impose d'avantage de
| communications dans l'équipe -- à mon avis, il se prète mal à de gros
| projets (mais il y a eu de gros projets en Smalltalk, et probablement en
| Lisp).
Je crois que le sujet n'est pas vraiment une opposition entre typage
statique et typage dynamique. C'est plutôt une question de résolution
retardée vs résolution « précoce ». Par exemple, les templates de C++
utilisent le typage statique mais le résolution des noms dépendant
n'est faite qu'à l'instantiation (comme les macros).
-- Gaby
Gabriel Dos Reis
[...]
| Mais pour revenir au point de départ : les langages à typage strictement
| statique ont prèsque tous, toujours, éxigé que les déclarations soient
| visible au point de l'utilisation.
C'est une concidence plus qu'une conséquence. Un langage à typage
statique et supportant la généricité (au sens template C++) peut sans
encombre implémenter la resolution retardée. Évidemment, cela suppose
qu'il n'y a pas de typage de « deuxième ordre » (i.e. les génériques
ne sont pas « typés » ou contraintes).
-- Gaby
Mickael Pointier
>>>> contrôle de type de C++, on puisse ce passer de forward
>>>> déclaration.
>>
>> C'est-à-dire ?
>>
>> Si on écrit par exemple :
>>
>> double f(int i) { return g(i+2); }
>> double g(int d) { return 2*d; }
>
> De la manière que les tests ne montreront pas en général qu'un
> programme est juste mais seulement qu'il est défaillant (Dijkstra), un
> petit exemple peut juste montrer qu'un modèle est défaillant : pas
> qu'il est juste.
>
>
> struct T {
> /* plein de bonnes choses. */
> };
>
> double g(int d) { return 2 * d; }
> // ...
>
> L'utilisation de g(0 dans f() est-elle une erreur ; est-ce la
> défnition qui ne colle pas avec l'utilisation ?
Avec la facon dont je vois les choses, les prototypes déclarés sont:
double f(T t);
double g(int d);
je considère que l'utilisation vient après en terme d'importance, et
donc que c'est le "return g(t)+2;" qui ne colle pas avec aucune
définition connue de "g".
Si la règle de résolutions d'erreurs est consistance, je ne vois pas
(dans le cas que tu présentes ici au moins) où il peut y avoir de
problème.
Mike
Gabriel Dos Reis
Donc, une addition de déclarations *après* utilisation change
complètement la sémantique de ce qui est utilisé avant !!!
Tu peux m'expliquer comment tu types les programmes avec ce modèle et
comment la surcharge marhe et comment on est censé développer des
biblioothèques avec ça ?
| Si la règle de résolutions d'erreurs est consistance, je ne vois pas
| (dans le cas que tu présentes ici au moins) où il peut y avoir de
| problème.
Comme je l'ai dit plus haut, avec des exemples (petits ou pas), on
peut seulement montrer qu'il y a des problèmes -- et non pas qu'il n'y
a pas de problèmes.
-- Gaby
Arnaud Meurgues
> Il y avait deux philosophies : un typage dynamique lors de l'execution
> (lisp, smalltalk), et un typage statique lors de la compilation (la
> famille de Pascal).
Tu ranges l'inférence de type dans la catégorie « typage statique » ou
est-ce une catégorie à part ?
> «@compromises ». Moi, par exemple, je trouve Java un peu schizophrène à
> cet égard -- il n'arrive pas à savoir s'il veut avoir un typage statique
> ou un typage dynamique.
Ce qui n'est pas complètement étonnant puisqu'il revendique des racines
tant chez C++ que chez smalltalk.
> grand-père dont il dérive directement, c'est B, voire BCPL. Des langages
> sans type, c-à-d effectivement à typage dynamique. Mais un typage non
> vérifié ni par le compilateur ni à l'execution. Or, assez tôt dans
Ça me fait drôle d'associer « pas de typage » avec « typage dynamique ».
> Mais pour revenir au point de départ : les langages à typage strictement
> statique ont prèsque tous, toujours, éxigé que les déclarations soient
> visible au point de l'utilisation.
Oui. Mais est-ce vraiment une nécessité ?
Comment, par exemple, le compilateur Java traite-t-il un appel de
fonction défini pourtant après la fonction dans laquelle il est effectué ?
Ou même en C++. Pourquoi :
void f() { g(); }
void g() {}
Ne compile pas alors que :
class C {
void f() { g(); }
void g() {}
};
compile sans problème ?
J'imagine que la réponse tient dans la capacité de C++ à faire de la
compilation séparée (c'est là qu'on rejoint le problème de compilation
séparée, même si le but premier est le typage). D'où l'idée, je pense,
de Mickael, de centraliser tous les indentifiants d'un projet/programme
pour permettre de faire, au sein d'un programme complet, ce qu'on peut
actuellement faire au sein d'une unité de compilation.
En revanche, cela risque effectivement de repousser des détections de
problème à l'édition de lien au lieu de les détecter dès la compilation.
Par ailleurs, plus j'y réfléchis, plus je trouve que, finalement, ce
n'est pas vraiment une bonne idée parce que cela va à l'encontre de
l'usage d'interfaces. Utiliser un symbole qui n'est pas prélablement
défini (au moins par son interface) me semble finalement une mauvaise idée.
> En effet. Je me pose depuis longtemps la question pourquoi aucun
> compilateur ne connaît le concepte de bibliothèque fermée. C-à-d que
> j'aurais un fichier qui pour moi est un tout, et qui comporterait à la
> fois les en-têtes (probablement précompilés) et les objets.
Oui. Ce serait franchement une bonne idée. C'est ce qui existait dans le
langage (le E) que j'utilisais sur Amiga (qui n'avait donc pas
d'entête). Mais c'est finalement proche de ce qui existe en Java, et
encore plus proche de ce que fait .NET.
>>D'ailleurs, il me semble que VisualAge a un modèle de compilation du
>>type de celui dont tu parles, et il a la prétention d'être un
>>compilateur C++.
> Peut-être. Je ne sais pas quel est l'évolution de Visual Age
> dernièrement. Je sais que quand on me l'a présenté la première fois, il
> n'était pas conforme,
Certes. Mais bon nombre de compilateurs ont la prétention d'être des
compilateurs C++ sans pour autant être conforme. :)
> parce que le compilateur voyait le contenu de tous
> les en-têtes, que j'ai fait un #include ou non.
C'est effectivement un problème. Une trop large permission de
visibilité. J'imagine que ce n'est pas une modification fondamentale de
leur compilo que de rectifier le tir.
De plus, si cela implique une utilisation "virtuelle" des directive
d'inclusion (au moins pour les includes standard), ça doit permettre de
n'inclure, avec un include, que ce qui est déclaré dans cet include. Un
mapping de l'entête inclue avec les fonctions qui deviennent visible
permet de traiter ça beaucoup plus souplement que le système d'inclusion
préprocessée habituel.
> l'époque, les gens d'IBM ont réconnu que c'était une erreur, et ont
> exprimé leur intention de le corriger. Mais depuis, je n'entends plus
> parler du tout de Visual Age.
Je ne sais pas trop. Je pourrais faire quelques essais ici. On devrait
avoir Visual Age. De quelle version s'agissait-il lorsque tu en as
entendu parler ?
Arnaud
Mickael Pointier
> d'un modèle de compilation. Comme je l'ai expliqué à Arnaud, c'est un
> problème de typage et non celui du modèle de compilation.
Il y aurais quelque part une explication claire de ce qu'est exactement
un modèle de compilation ?
Avoir une discussion précise sur quelque chose dont on n'a qu'une
connaissance approximative peut difficilement déboucher sur quelque
chose de productif :)
Mike
Mickael Pointier
>>>> templates. L'implémentation CFront n'était pas très éloignée
>>>> d'un macro
>>
>>> Les templates aujourd'hui ont-ils vraiment changé sur cet aspect ?
>>
>> Oui et non. La récherche en deux temps des symboles les en éloigne
>> déjà considérablement, puisqu'elle permet au compilateur de pouvoir
>> faire une bonne partie de la compilation avant l'instantiation.
>
> Ce qui est ennuyeux dans cet modèle schizophrène des templates, c'est
> que d'un côté on fait une recherche de nom en deux et de
> l'autre côté, on ne requiert pas que les erreurs les plus fragrantes
> soient diagnostiqués lors du parsing du template -- ce qui leur donne
> un goût très prononcé de macro.
D'ailleur à ce propos, pourquoi est-ce que l'on a toujours la division
preprocesseur/compilateur en C++ ?
N'aurait t'il pas été possible de virer le préprocesseur et de rajouter
directement dans le langage la notions de compilation conditionelle ?
Mike
Arnaud Meurgues
> Mainitenant, prenons
>
> struct T {
> /* plein de bonnes choses. */
> };
>
> doube f(T t) { return g(t) + 2; }
> double g(int d) { return 2 * d; }
> // ...
>
> L'utilisation de g(0 dans f() est-elle une erreur ; est-ce la
> défnition qui ne colle pas avec l'utilisation ?
On peut très bien imaginer que la réponse à cette question soit retardée
jusqu'à ce que toutes les fonctions du programme soient connues.
Et par ailleurs :
class C {
struct T {
/* plein de bonnes choses. */
};
doube f(T t) { return g(t) + 2; }
double g(int d) { return 2 * d; }
// ...
};
compile très bien. Pourtant, le problème est similaire (à part que la
classe est un scope fermé).
Arnaud
Arnaud Meurgues
> N'aurait t'il pas été possible de virer le préprocesseur et de rajouter
> directement dans le langage la notions de compilation conditionelle ?
Toi, tu devrais te mettre au C#... ;-)
(oui, je sais, pour les jeux sur Nintendo, c'est pas idéal)
Arnaud
Gabriel Dos Reis
| >>>> - La norme a beaucoup changé la façon que fonctionne les
| >>>> templates. L'implémentation CFront n'était pas très éloignée
| >>>> d'un macro
| >>
| >>> Les templates aujourd'hui ont-ils vraiment changé sur cet aspect ?
| >>
| >> Oui et non. La récherche en deux temps des symboles les en éloigne
| >> déjà considérablement, puisqu'elle permet au compilateur de pouvoir
| >> faire une bonne partie de la compilation avant l'instantiation.
| >
| > Ce qui est ennuyeux dans cet modèle schizophrène des templates, c'est
| > que d'un côté on fait une recherche de nom en deux et de
| > l'autre côté, on ne requiert pas que les erreurs les plus fragrantes
| > soient diagnostiqués lors du parsing du template -- ce qui leur donne
| > un goût très prononcé de macro.
|
| D'ailleur à ce propos, pourquoi est-ce que l'on a toujours la division
| preprocesseur/compilateur en C++ ?
Parce que Paris ne s'est pas en fait un jour ?
-- Gaby
Mickael Pointier
Bein non, ou alors on ne parles pas de la même chose.
Si le compilateur n'essaye pas d'inventer des types (comme le compilo C
qui par défaut considère qu'une fonction par défaut prend un int et
retourn un int), et n'essaye pas non plus de résoudre les choses au vol,
on peut le faire en plusieurs passes.
Pour résoudre le genre de cas que tu propose, il faudrait qu'il se passe
ca:
Lors de la compilation de chaque unité le compilateur parse tout, et
commence par faire des "petits tas". Il note les déclarations de type,
les prototypes de fonctions et méthodes, et met de coté pour l'instant
les implémentations.
C'est seulement dans une passe ultérieure qu'on traite l'implémentation.
Donc fatalement lorsque le compilateur il foit un "g(t)" il sait déja
que ca n'est pas valide vu que la seule déclaratino de fonction qu'il
connaisse pour g est "double g(int)".
Donc oui si tu veux, c'est APRES dans le code source. Mais je ne vois
pas ce que ca change si l'ensemble est cohérent par rapport à lui même.
Ca permet juste de mettre les choses dans le désordre, de ne plus avoir
de faire de pré-déclaration de type, etc...
A part le fait que c'est certainement plus lent à compiler, je ne vois
rien de particulièrement outrageux la dedans ?
> Tu peux m'expliquer comment tu types les programmes avec ce modèle et
> comment la surcharge marhe et comment on est censé développer des
> biblioothèques avec ça ?
Bein la surcharge marche toujours, c'est juste que tu n'est plus obligé
de faire des contorsions pour être sur que toutes les variantes sont
présentes avant l'utilisation. On peut même imaginer que ca peut éviter
des problèmes de mauvaise instantiation dans des cas extrêmes:
On est d'accord sur le fait que dans la résolution de surcharge le
compilateur choisi la variante qui correspond au typage des paramètres,
et dans le cadre d'opérateurs de conversion disponbibles peut s'arroger
le droit d'utiliser une variante qui ne correspond pas au type donné en
paramètre s'il existe une règle de conversion qui va bien ?
Bon bein dans le truc que je propose on est sûr que le compilateur va
choisir le plus adapté, sans avoir à vérifier que l'include qui déclare
les opérateurs de conversion ET les déclarations de fonctions
surchargées sont bien toutes placés avant l'utilisation (ce qui peut
devenir problématique si on considère que l'utilisation peut se faire
dans une méthode inline d'une classe (là ca devient casse tête pour être
sur que tout est bien défini dans le bon ordre.))
Au niveau des bibliothèques je ne vois pas ca que ca change non plus. Ca
ne change rien au niveau du degré de visibilité des éléments, ca garanti
juste que tout est pris dans un ordre qui fait que l'on a plus à se
préoccuper de l'ordre des #include. rien de plus.
>> Si la règle de résolutions d'erreurs est consistance, je ne vois pas
>> (dans le cas que tu présentes ici au moins) où il peut y avoir de
>> problème.
>
> Comme je l'ai dit plus haut, avec des exemples (petits ou pas), on
> peut seulement montrer qu'il y a des problèmes -- et non pas qu'il n'y
> a pas de problèmes.
Soit, mais je suppose que depuis le temps que James et toi fréquentez
les comités de normalisation, et recevez des remarques et suggestions
sur l'évolution du C++ vous devez commencer à pas être mauvais au niveau
de la capacité à repérer les gros défaut dans les "fausses bonnes idées"
:)
Mike
Gabriel Dos Reis
| Gabriel Dos Reis wrote:
| > Mainitenant, prenons
| > struct T {
| > /* plein de bonnes choses. */ };
| > doube f(T t) { return g(t) + 2; }
| > double g(int d) { return 2 * d; }
| > // ...
| > L'utilisation de g(0 dans f() est-elle une erreur ; est-ce la
| > défnition qui ne colle pas avec l'utilisation ?
|
| On peut très bien imaginer que la réponse à cette question soit
| retardée jusqu'à ce que toutes les fonctions du programme soient
| connues.
C'est une réponse possible. Simplement il n'est plus possible d'être
sûr de la sémantique d'un construction, i.e. de son typage, si on n'a
pas vu ce qui sera ajouté plus tard.
Je reposes ma question : comment tu décris explicitement e typage dans
ce modèle et comment est-on censé développer des bibliothèques avec ça ?
(Pour les non-lispeurs, ce problème est plus ou moins le problème de
« fun-args » connus depuis les années 60, résolu par la notion de
portée lexicale... i.e. ce qu'on a dans dans C++ actuellement ;-)
| Et par ailleurs :
|
| class C {
| struct T {
| /* plein de bonnes choses. */
| };
|
| doube f(T t) { return g(t) + 2; }
| double g(int d) { return 2 * d; }
| // ...
| };
|
| compile très bien. Pourtant, le problème est similaire (à part que la
| classe est un scope fermé).
Non, le problème n'est pas similaire, car, comme tu le remarques, une
fois la classe C définie, la sémantique devient fixée pour toujours.
Il est possible dans ce cas d'écrire une expression et d'être sûr de
sa semantique, i.e. de son typage, alors que dans le modèle que vous
proposez, non. Rrtour à la case départ de ma remarque.
-- Gaby
Gabriel Dos Reis
Gabriel Dos Reis
[...]
| > «@compromises ». Moi, par exemple, je trouve Java un peu schizophrène à
| > cet égard -- il n'arrive pas à savoir s'il veut avoir un typage statique
| > ou un typage dynamique.
|
| Ce qui n'est pas complètement étonnant puisqu'il revendique des
| racines tant chez C++ que chez smalltalk.
???
| > grand-père dont il dérive directement, c'est B, voire BCPL. Des langages
| > sans type, c-à-d effectivement à typage dynamique. Mais un typage non
| > vérifié ni par le compilateur ni à l'execution. Or, assez tôt dans
|
| Ça me fait drôle d'associer « pas de typage » avec « typage dynamique ».
Ce sont en effet deux choses complètement différentes. Pas de typage
veut dire en fait toutes les valeurs ont même type et typage
dynamique veut dire que la vérification se fait à l'exécution.
| > Mais pour revenir au point de départ : les langages à typage strictement
| > statique ont prèsque tous, toujours, éxigé que les déclarations soient
| > visible au point de l'utilisation.
|
| Oui. Mais est-ce vraiment une nécessité ?
Un corollaire plus ou moins.
Dans un langage à typage statique (strict) les types effectifs des
expressions sont connus par une analyse ststique du programme texte.
Le langage Pascal (moins les variants et quelques absurdités) est un
prototype classique. C'est très frustant de programmer avec un tel
langage.
| Comment, par exemple, le compilateur Java traite-t-il un appel de
| fonction défini pourtant après la fonction dans laquelle il est
| effectué ?
|
| Ou même en C++. Pourquoi :
|
| void f() { g(); }
| void g() {}
|
| Ne compile pas alors que :
|
| class C {
| void f() { g(); }
| void g() {}
| };
|
| compile sans problème ?
Déjà expliqué dans un autre poste : évaluation des définitions dans
la portée fermée de la classe comme si cela avait été ecrit :
class C {
void f();
void g();
};
inline void C::f() { g(); }
inline void C::g() { }
et c'est cette dernière que le compilateur traite et pas autre chose.
À un moment, il faut fermer la porte. There is no free lunch.
| J'imagine que la réponse tient dans la capacité de C++ à faire de la
| compilation séparée (c'est là qu'on rejoint le problème de compilation
| séparée, même si le but premier est le typage).
Non, comme je l'ai déjà montré, c'est la capacité à faire un typage
plus sûr.
| D'où l'idée, je pense,
| de Mickael, de centraliser tous les indentifiants d'un
| projet/programme pour permettre de faire, au sein d'un programme
| complet, ce qu'on peut actuellement faire au sein d'une unité de
| compilation.
C'est du placebo.
| En revanche, cela risque effectivement de repousser des détections de
| problème à l'édition de lien au lieu de les détecter dès la
| compilation.
|
| Par ailleurs, plus j'y réfléchis, plus je trouve que, finalement, ce
| n'est pas vraiment une bonne idée parce que cela va à l'encontre de
| l'usage d'interfaces. Utiliser un symbole qui n'est pas prélablement
| défini (au moins par son interface) me semble finalement une mauvaise
| idée.
Tu veux dire qu'utiliser un symbole dont on ne connaît pas le type est
une mauvaise idée, c'est ce que je disais depuis le début ;-)
Le problème du « fun-args » est connu depuis un moment (et on connait
le remède :-)
[...]
| Certes. Mais bon nombre de compilateurs ont la prétention d'être des
| compilateurs C++ sans pour autant être conforme. :)
Qui a vraiment besoin d'un compilateur conforme ?
[ Demi ;-) ]
-- Gaby
Gabriel Dos Reis
si « c'est le " return g(t) + 2 " qui ne colle avec aucune défnition
connue de "g" » alors il est en erreur.
Ou alors tu as une autre définition de typage, dans ce cas, ce serait
bien que tu la dises.
| ou alors on ne parles pas de la même chose.
Ma question etait
# L'utilisation de g(0 dans f() est-elle une erreur ; est-ce la
# défnition qui ne colle pas avec l'utilisation ?
À quoi répondais-tu ?
| Si le compilateur n'essaye pas d'inventer des types (comme le compilo C
| qui par défaut considère qu'une fonction par défaut prend un int et
| retourn un int), et n'essaye pas non plus de résoudre les choses au vol,
| on peut le faire en plusieurs passes.
Faire quoi exactement en plusieurs passes ?
J'écris uen expression dont je veux connaître la sémantique. Qu'est-ce
qu'il faut passer plusieurs fois ?
| Pour résoudre le genre de cas que tu propose, il faudrait qu'il se passe
| ca:
| Lors de la compilation de chaque unité le compilateur parse tout, et
| commence par faire des "petits tas". Il note les déclarations de type,
| les prototypes de fonctions et méthodes, et met de coté pour l'instant
| les implémentations.
| C'est seulement dans une passe ultérieure qu'on traite l'implémentation.
| Donc fatalement lorsque le compilateur il foit un "g(t)" il sait déja
| que ca n'est pas valide vu que la seule déclaratino de fonction qu'il
| connaisse pour g est "double g(int)".
Donc cela rejoint l'observation que je faisais
Donc, une addition de déclarations *après* utilisation change
complètement la sémantique de ce qui est utilisé avant !!!
[...]
| > Tu peux m'expliquer comment tu types les programmes avec ce modèle et
| > comment la surcharge marhe et comment on est censé développer des
| > biblioothèques avec ça ?
|
| Bein la surcharge marche toujours,
Il ne suffit pas de me le dire comme une prière : il faut le montrer.
| c'est juste que tu n'est plus obligé
| de faire des contorsions pour être sur que toutes les variantes sont
| présentes avant l'utilisation.
Mais peut-on en être sûr si tout dépend de ce qui suit suit et non de
ce qui précède. À moins d'inventer une boule de cristal, je ne sais
pas comment tu veux faire.
| On peut même imaginer que ca peut éviter
| des problèmes de mauvaise instantiation dans des cas extrêmes:
Je n'ai jamsis dit que le modèle que tu proposais était le pire
imaginable :-)
[...]
| Au niveau des bibliothèques je ne vois pas ca que ca change non plus. Ca
| ne change rien au niveau du degré de visibilité des éléments, ca garanti
Ça change beaucoup de choses : l'auteur d'une biliothèque ne sait plus
la sémantique de ses routines. Remarque, dans ce cas, cela simplifie
le travail de documentation :-)
-- Gaby
Arnaud Meurgues
> | Ce qui n'est pas complètement étonnant puisqu'il revendique des
> | racines tant chez C++ que chez smalltalk.
>
> ???
Ben oui. On lit ça partout. Au hasard, sur google :
http://www.cse.ucsc.edu/~pohl/Winter01/LL4/tsld002.htm
permier lien avec "java origins".
> Tu veux dire qu'utiliser un symbole dont on ne connaît pas le type est
> une mauvaise idée, c'est ce que je disais depuis le début ;-)
Vi. Comme quoi, avec du temps, je finis par te comprendre. :)
> Qui a vraiment besoin d'un compilateur conforme ?
:-)
Arnaud
Arnaud Debaene
>
> En passant, je travaillais sur un cas aujourd'hui où j'aurais bien été
> content d'avoir export. J'ajoutais de la fonctionnalité à un template,
> Plus précisement, j'ajoutais une fonction à une template de classe,
> dont une instance était contenue dans une classe non templatée qui
> servait à peu près partout. Évidemment, il n'y avait qu'une seule
> source qui utilisait la nouvelle fonction. Mais du fait que ma classe
> non-templatée incluait l'en-tête avec la définition du template
> (obligatioire, puisqu'elle en avait un membre qui en était une
> instance), et que l'entête de cette classe était inclue dans un
> trentaine de fichiers, chaque fois que je modifiais l'implémentation
> de cette nouvelle fonction, make récompilait une trentaine de
> fichiers, tandis qu'un seul aurait suffit. D'après ce que j'ai compris
> de ce que m'a dit David Vandervoorde, et selon les expériences de
> Jean-Marc, je crois qu'avec Comeau (à la place de g++ 3.2.2), il n'en
> aurait récompilé qu'un.
Je suis loin d'avoir le niveau pour suivre toutes les subtilités de
cette discussion, mais il me semble malgré tout qu'un point ressort
sur lequel tout le monde est d'accord : le seul (mais non négligeable)
intérêt de export, c'est de réduire les dépendances.
Jusque là, fort bien. Mais si j'ai bien suivi les débats (notammment
Jean Marc ici <pxbvfyp...@news.bourguet.org>), il semble que le
gain (ou la perte!) réel(le) obtenu(e) en matière de dépendance
dépende du modèle d'implémentation des templates choisi par le
compilateur.
A partir de là, je me demande s'il ne faudrait pas au moins préciser
dans la norme ce qu'export *doit* apporter en matière de dépendances.
Je sais bien que cela ne fait pas partie du comportement observable du
programme, mais pour l'instant, tout ce que dit ou implique la norme,
c'est (je caricature) "export n'apporte rien à la sémantique de votre
programme, mais il se *pourrait* que cela réduise vos dépendances et
vos temps de compilation". Est-ce suffisant pour justifier toutes les
difficultés d'implémentation? Je n'en sais rien...
C'est au fond assez proche de ce que promets inline dans la norme
(sauf que inline s'occupe des temps d'exécution, pas de compilation),
c'est à dire pas grand chose à part une *possibilité* d'optimisation.
Arnaud
Arnaud Meurgues
> C'est une réponse possible. Simplement il n'est plus possible d'être
> sûr de la sémantique d'un construction, i.e. de son typage, si on n'a
> pas vu ce qui sera ajouté plus tard.
>
> Je reposes ma question : comment tu décris explicitement e typage dans
> ce modèle et comment est-on censé développer des bibliothèques avec ça ?
J'ai du mal à voir en quoi le modèle actuel évite les même problèmes.
Tu peux linker un programme avec une fonction qui a une définition
différente de celle prévue par l'auteur de la bibliothèque et la
sémantique de sa bibliothèque change donc.
Parce que :
- soit une bibliothèque est indépendante (elle contient tout le code
dont elle a besoin pour fonctionner) et rien n'empêche de faire la même
chose dans le modèle proposé par Mickael.
- soit une bibliothèque dépend de symbols qu'elle n'inclut pas, et
elle ne maîtrise pas alors la sémantique qui sera donnée pour ces
symboles une fois l'édition de lien effectuée.
ou alors, il y a quelque chose que tu veux dire qui m'échappe (ce qui
est probable) et j'aimerais savoir quoi.
Arnaud
James Kanze
> ka...@gabi-soft.de (James Kanze) writes:
> [...]
En principe, il n'y a pas de problème à supporter les declarations après
l'utilisation. Il suffit d'une passe de compilateur en plus, au départ,
qui ne traite que les déclarations. En C++, c'est moins évident, parce
que pour savoir si on a affaire à une declaration ou non, il faut savoir
la définition des symboles dans l'instruction.
Mais le but de mon exposé était plutôt dans la direction : qu'on le peut
ou non, ce n'est pas bien de pouvoir utiliser les symboles qui ne sont
définis que plus tard.
Gabriel Dos Reis
[...]
| Jusque là, fort bien. Mais si j'ai bien suivi les débats (notammment
| Jean Marc ici <pxbvfyp...@news.bourguet.org>), il semble que le
| gain (ou la perte!) réel(le) obtenu(e) en matière de dépendance
| dépende du modèle d'implémentation des templates choisi par le
| compilateur.
|
| A partir de là, je me demande s'il ne faudrait pas au moins préciser
| dans la norme ce qu'export *doit* apporter en matière de dépendances.
La norme n'est pas le lieu pour spécifier les details d'implémentations.
La norme ne requiert pas qu'une implémentation C++ soit utile.
-- Gaby