// une classe simple
class B {
public:
B(int j) : k(j) {}
inline void run () {
throw Excp("exception imprévue dans le run");
}
virtual ~B () { throw Excp("Bad B"); }
private:
int k;
};
Je comprend que l'exception déclenchée dans b.run() provoque la sortie
du bloc et donc la destruction de l'objet b. Une nouvelle exception est
alors levée. Je pensais que mes try/catch résolverais le problème, mais
ce n'est pas le cas. J'ai un message
Executable tests has exited due to signal 6 (SIGABRT).
Et rien d'autre. C'est un vrai plantage. Si je supprime l'un des deux
throw, j'ai le résultat attendu.
J'utilise gcc 3.3 sur MacOS 10.3.5.
Est-ce que quelqu'un a des explications ? Je sais comment m'en dépétrer,
ce qui m'intéresse c'est le pourquoi du comment.
Je regrette que le dernier XC++ soit encore aussi anti-export. :-(
Je ne l'ai pas lu. Mais bon, si on n'utilise pas le bon mécanisme d'instantiation, export n'a que des avantages de "propreté" et c'est vrai que dans ces conditions on peut douter de son intérêt.
Mais de là à conseiller « avoid export » ?
Bah, il y a tout de même des précédents, comme James qui, encore aujourd'hui, conseille généralement « avoid <iostream> » à cause des problèmes de portabilité...
Pour bien des gens, la question ne se pose pas : le verbe « avoid » est mal choisi quand c'est quelque chose qu'on ne peut même pas utiliser, mais le résultat est le même : Herb peut prétendre que tout le monde (ou presque) suit son conseil ou pense comme lui :-)
(Il me semble que ce serait facile d'avoir tous les compilateurs pressés d'implémenter export, il suffirait que gcc le supporte...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Dans le message m3sm7ydfui.fsf@merlin.cs.tamu.edu,
Jean-Marc Bourguet <jm@bourguet.org> writes:
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
Je regrette que le dernier XC++ soit encore aussi anti-export. :-(
Je ne l'ai pas lu. Mais bon, si on n'utilise pas le bon
mécanisme d'instantiation, export n'a que des avantages de
"propreté" et c'est vrai que dans ces conditions on peut
douter de son intérêt.
Mais de là à conseiller « avoid export » ?
Bah, il y a tout de même des précédents, comme James qui, encore
aujourd'hui, conseille généralement « avoid <iostream> » à cause
des problèmes de portabilité...
Pour bien des gens, la question ne se pose pas : le verbe « avoid »
est mal choisi quand c'est quelque chose qu'on ne peut même pas
utiliser, mais le résultat est le même : Herb peut prétendre que
tout le monde (ou presque) suit son conseil ou pense comme lui :-)
(Il me semble que ce serait facile d'avoir tous les compilateurs
pressés d'implémenter export, il suffirait que gcc le supporte...)
--
Michel Michaud mm@gdzid.com
http://www.gdzid.com
FAQ de fr.comp.lang.c++ :
http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Je regrette que le dernier XC++ soit encore aussi anti-export. :-(
Je ne l'ai pas lu. Mais bon, si on n'utilise pas le bon mécanisme d'instantiation, export n'a que des avantages de "propreté" et c'est vrai que dans ces conditions on peut douter de son intérêt.
Mais de là à conseiller « avoid export » ?
Bah, il y a tout de même des précédents, comme James qui, encore aujourd'hui, conseille généralement « avoid <iostream> » à cause des problèmes de portabilité...
Pour bien des gens, la question ne se pose pas : le verbe « avoid » est mal choisi quand c'est quelque chose qu'on ne peut même pas utiliser, mais le résultat est le même : Herb peut prétendre que tout le monde (ou presque) suit son conseil ou pense comme lui :-)
(Il me semble que ce serait facile d'avoir tous les compilateurs pressés d'implémenter export, il suffirait que gcc le supporte...)
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
Gabriel Dos Reis
"Michel Michaud" writes:
[...]
| (Il me semble que ce serait facile d'avoir tous les compilateurs | pressés d'implémenter export, il suffirait que gcc le supporte...)
Les implémenteurs écoutent en général leurs utilisateurs ; si on dit à ces utilisateurs « avoid export », ceux-ci n'iront pas presser les implémenteurs, qui à leur tour diront que leurs utilisateurs n'en ont pas besoin, ce qui à son tour ... Comment appelle-t-on « self-fulfilling prophecy » déjà ?
-- Gaby
"Michel Michaud" <mm@gdzid.com> writes:
[...]
| (Il me semble que ce serait facile d'avoir tous les compilateurs
| pressés d'implémenter export, il suffirait que gcc le supporte...)
Les implémenteurs écoutent en général leurs utilisateurs ; si on dit à
ces utilisateurs « avoid export », ceux-ci n'iront pas presser les
implémenteurs, qui à leur tour diront que leurs utilisateurs n'en ont
pas besoin, ce qui à son tour ... Comment appelle-t-on
« self-fulfilling prophecy » déjà ?
| (Il me semble que ce serait facile d'avoir tous les compilateurs | pressés d'implémenter export, il suffirait que gcc le supporte...)
Les implémenteurs écoutent en général leurs utilisateurs ; si on dit à ces utilisateurs « avoid export », ceux-ci n'iront pas presser les implémenteurs, qui à leur tour diront que leurs utilisateurs n'en ont pas besoin, ce qui à son tour ... Comment appelle-t-on « self-fulfilling prophecy » déjà ?
-- Gaby
drkm
Gabriel Dos Reis writes:
Comment appelle-t-on « self-fulfilling prophecy » déjà ?
Prédictions auto-réalisatrices ? Comme la prédiction de baisse de la valeur d'une action en bourse, qui par son énonciation-même provoque une baisse de confiance, une augmentation des ventes de ces titres et donc ... une baisse de leur valeur ?
--drkm
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
Comment appelle-t-on
« self-fulfilling prophecy » déjà ?
Prédictions auto-réalisatrices ? Comme la prédiction de baisse de
la valeur d'une action en bourse, qui par son énonciation-même
provoque une baisse de confiance, une augmentation des ventes de ces
titres et donc ... une baisse de leur valeur ?
Comment appelle-t-on « self-fulfilling prophecy » déjà ?
Prédictions auto-réalisatrices ? Comme la prédiction de baisse de la valeur d'une action en bourse, qui par son énonciation-même provoque une baisse de confiance, une augmentation des ventes de ces titres et donc ... une baisse de leur valeur ?
--drkm
google
Fabien LE LEZ wrote:
On 28 Oct 2004 04:57:05 -0500, Gabriel Dos Reis :
Tu veux dire que tu ne serais jamais tenté par utiliser des compilos basés sur le front-end EDG en production ?
Pas dans l'immédiat, en tout cas. Surtout après avoir lu les réponses à <news:. Il est possible qu'à moyen terme je l'utilise, comme il est possible que d'autres compilos finissent par l'implémenter.
Le dernier compilo Intel implemente "export."
Quoi qu'il en soit, dans l'immédiat "export" reste pour moi un sujet théorique, d'autant que je travaille sur des petits projets (quelques dizaines de milliers de lignes de code), qui sont compilables très vite (moins de deux minutes sur mon PC pour une recompilation complète) et ne nécessitent donc pas de méthodes spécifiques d'accélération de la compilation.
C'est vrai qu'en matiere de vitesse the compilation, des petits projets n'ont pas de problemes. Neanmoins, le modele de separation est quand-meme tres agreable pour ce genre de projet la aussi.
D'auters lecteurs ont d'autres perceptions que la mienne. Mais après avoir lu et relu plusieurs fois ce chapitre, je n'ai pas l'impression qu'il avait pour but d'expliquer à quoi il sert.
Effectivement.
C'est dommage.
C'est peut-être pas le but, d'autant que ses lecteurs sont sensés déjà connaître les bases -- et donc avoir une bonne idée de ce qu'est "export".
Je ne pense pas que ce soit le cas. Herb a ecrit ce chapitre sur bases de rumeurs (y compris des betises que j'avais communique avant d'avoir implemente export). J'ai essaye a plusiers fois de convaincre Herb des erreures techniques (grossieres, malheureusement) dans ce chapitre, mais il semble convaincu que je ne comprend pas export %^/ Le faite que WG21/J16 a aussi refute ses arguments ne l'a pas dissuade non plus.
David
Fabien LE LEZ <gramster@gramster.com> wrote:
On 28 Oct 2004 04:57:05 -0500, Gabriel Dos Reis <gdr@cs.tamu.edu>:
Tu veux dire que tu ne serais jamais tenté par utiliser des compilos
basés sur le front-end EDG en production ?
Pas dans l'immédiat, en tout cas.
Surtout après avoir lu les réponses à
<news:8batm0d2tbu4faj212k0219earrkm7v4g4@4ax.com>.
Il est possible qu'à moyen terme je l'utilise, comme il est possible
que d'autres compilos finissent par l'implémenter.
Le dernier compilo Intel implemente "export."
Quoi qu'il en soit, dans l'immédiat "export" reste pour moi un sujet
théorique, d'autant que je travaille sur des petits projets (quelques
dizaines de milliers de lignes de code), qui sont compilables très
vite (moins de deux minutes sur mon PC pour une recompilation
complète) et ne nécessitent donc pas de méthodes spécifiques
d'accélération de la compilation.
C'est vrai qu'en matiere de vitesse the compilation, des petits
projets n'ont pas de problemes. Neanmoins, le modele de
separation est quand-meme tres agreable pour ce genre de
projet la aussi.
D'auters lecteurs ont d'autres perceptions que la mienne. Mais après
avoir lu et relu plusieurs fois ce chapitre, je n'ai pas l'impression
qu'il avait pour but d'expliquer à quoi il sert.
Effectivement.
C'est dommage.
C'est peut-être pas le but, d'autant que ses lecteurs sont sensés déjà
connaître les bases -- et donc avoir une bonne idée de ce qu'est
"export".
Je ne pense pas que ce soit le cas. Herb a ecrit ce chapitre sur
bases de rumeurs (y compris des betises que j'avais communique
avant d'avoir implemente export). J'ai essaye a plusiers fois de
convaincre Herb des erreures techniques (grossieres, malheureusement)
dans ce chapitre, mais il semble convaincu que je ne comprend pas
export %^/ Le faite que WG21/J16 a aussi refute ses arguments ne
l'a pas dissuade non plus.
Tu veux dire que tu ne serais jamais tenté par utiliser des compilos basés sur le front-end EDG en production ?
Pas dans l'immédiat, en tout cas. Surtout après avoir lu les réponses à <news:. Il est possible qu'à moyen terme je l'utilise, comme il est possible que d'autres compilos finissent par l'implémenter.
Le dernier compilo Intel implemente "export."
Quoi qu'il en soit, dans l'immédiat "export" reste pour moi un sujet théorique, d'autant que je travaille sur des petits projets (quelques dizaines de milliers de lignes de code), qui sont compilables très vite (moins de deux minutes sur mon PC pour une recompilation complète) et ne nécessitent donc pas de méthodes spécifiques d'accélération de la compilation.
C'est vrai qu'en matiere de vitesse the compilation, des petits projets n'ont pas de problemes. Neanmoins, le modele de separation est quand-meme tres agreable pour ce genre de projet la aussi.
D'auters lecteurs ont d'autres perceptions que la mienne. Mais après avoir lu et relu plusieurs fois ce chapitre, je n'ai pas l'impression qu'il avait pour but d'expliquer à quoi il sert.
Effectivement.
C'est dommage.
C'est peut-être pas le but, d'autant que ses lecteurs sont sensés déjà connaître les bases -- et donc avoir une bonne idée de ce qu'est "export".
Je ne pense pas que ce soit le cas. Herb a ecrit ce chapitre sur bases de rumeurs (y compris des betises que j'avais communique avant d'avoir implemente export). J'ai essaye a plusiers fois de convaincre Herb des erreures techniques (grossieres, malheureusement) dans ce chapitre, mais il semble convaincu que je ne comprend pas export %^/ Le faite que WG21/J16 a aussi refute ses arguments ne l'a pas dissuade non plus.
David
google
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
Bon, OK, j'ai oublié le "presque". L'idée est que implémenter "export" dans Comeau semble avoir été un travail titanesque,
2 petites sociétés (4 personnes en tout) ont réussit à le faire en quoi? 4 ans? et à ne pas crouler -- donc c'est pas du temps plein. Je ne qualifierais pas ça de titanesque. J'ai vu des plus gros investissements -- plus gros que 16 homme-ans je veux dire -- être envoyés à la trappe parce qu'on a racheté une autre société. Bon, on n'est pas aussi petit qu'EDG et Comeau, mais en capitalisation boursière on ne fait qu'un pourcent de Microsoft.
Pour clarification: Nous etions 3 personnes (Comeau ne fait que recompiler nos sources; je le compte pas dans l'effort d'implementation, bien que jusqu'a recemment c'etait grace a lui que l'implementation etait accessible).
L'implementation a pris 1 1/2 ans et pendant cette meme periode nous avons ajoute un mode de compatibilite gcc (e.g., permettant de compiler le kernel Linux): Pas un petit projet non plus. Et bien sure, nous avons aussi continue a repondre au besoins immediat de nos clients.
Cela dit, c'est vrai que export a pris plus de temps que d'autres elements du C++.
(Comme d'habitude, mes excuses pour les fautes de francais.)
David
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Bon, OK, j'ai oublié le "presque". L'idée est que
implémenter "export" dans Comeau semble avoir été un
travail titanesque,
2 petites sociétés (4 personnes en tout) ont réussit à le
faire en quoi? 4 ans? et à ne pas crouler -- donc c'est pas
du temps plein. Je ne qualifierais pas ça de titanesque.
J'ai vu des plus gros investissements -- plus gros que 16
homme-ans je veux dire -- être envoyés à la trappe parce
qu'on a racheté une autre société. Bon, on n'est pas aussi
petit qu'EDG et Comeau, mais en capitalisation boursière on
ne fait qu'un pourcent de Microsoft.
Pour clarification: Nous etions 3 personnes (Comeau ne fait
que recompiler nos sources; je le compte pas dans l'effort
d'implementation, bien que jusqu'a recemment c'etait grace
a lui que l'implementation etait accessible).
L'implementation a pris 1 1/2 ans et pendant cette meme
periode nous avons ajoute un mode de compatibilite gcc (e.g.,
permettant de compiler le kernel Linux): Pas un petit projet
non plus. Et bien sure, nous avons aussi continue a repondre
au besoins immediat de nos clients.
Cela dit, c'est vrai que export a pris plus de temps que d'autres
elements du C++.
(Comme d'habitude, mes excuses pour les fautes de francais.)
Bon, OK, j'ai oublié le "presque". L'idée est que implémenter "export" dans Comeau semble avoir été un travail titanesque,
2 petites sociétés (4 personnes en tout) ont réussit à le faire en quoi? 4 ans? et à ne pas crouler -- donc c'est pas du temps plein. Je ne qualifierais pas ça de titanesque. J'ai vu des plus gros investissements -- plus gros que 16 homme-ans je veux dire -- être envoyés à la trappe parce qu'on a racheté une autre société. Bon, on n'est pas aussi petit qu'EDG et Comeau, mais en capitalisation boursière on ne fait qu'un pourcent de Microsoft.
Pour clarification: Nous etions 3 personnes (Comeau ne fait que recompiler nos sources; je le compte pas dans l'effort d'implementation, bien que jusqu'a recemment c'etait grace a lui que l'implementation etait accessible).
L'implementation a pris 1 1/2 ans et pendant cette meme periode nous avons ajoute un mode de compatibilite gcc (e.g., permettant de compiler le kernel Linux): Pas un petit projet non plus. Et bien sure, nous avons aussi continue a repondre au besoins immediat de nos clients.
Cela dit, c'est vrai que export a pris plus de temps que d'autres elements du C++.
(Comme d'habitude, mes excuses pour les fautes de francais.)
David
Fabien LE LEZ
On 29 Oct 2004 08:24:57 -0700, (Daveed Vandevoorde):
Neanmoins, le modele de separation est quand-meme tres agreable pour ce genre de projet la aussi.
Qu'apporte-t-il exactement ?
Je veux dire, quels sont les avantages réels de "export" en-dehors d'un problème de temps de compilation ?
-- ;-)
On 29 Oct 2004 08:24:57 -0700, google@vandevoorde.com (Daveed
Vandevoorde):
Neanmoins, le modele de
separation est quand-meme tres agreable pour ce genre de
projet la aussi.
Qu'apporte-t-il exactement ?
Je veux dire, quels sont les avantages réels de "export" en-dehors
d'un problème de temps de compilation ?
On 29 Oct 2004 08:24:57 -0700, (Daveed Vandevoorde):
J'ai essaye a plusiers fois de convaincre Herb des erreures techniques (grossieres, malheureusement) dans ce chapitre
Quelles sont-elles ?
Merci d'avance...
-- ;-)
google
Gabriel Dos Reis wrote:
Matthieu Moy writes:
| Fabien LE LEZ writes: | | > Pas dans l'immédiat, en tout cas. | > Surtout après avoir lu les réponses à | > <news:. | > Il est possible qu'à moyen terme je l'utilise, comme il est possible | > que d'autres compilos finissent par l'implémenter. | | Sauf erreur de ma part, le compilateur Intel utilise aussi EDG.
C'est exact. Et ils ont exprès désactivé « export ». Va savoir pourquoi.
La versions la plus recente (sur Linux) la reactive.
| Fabien LE LEZ <gramster@gramster.com> writes:
|
| > Pas dans l'immédiat, en tout cas.
| > Surtout après avoir lu les réponses à
| > <news:8batm0d2tbu4faj212k0219earrkm7v4g4@4ax.com>.
| > Il est possible qu'à moyen terme je l'utilise, comme il est possible
| > que d'autres compilos finissent par l'implémenter.
|
| Sauf erreur de ma part, le compilateur Intel utilise aussi EDG.
C'est exact. Et ils ont exprès désactivé « export ». Va savoir pourquoi.
La versions la plus recente (sur Linux) la reactive.
| Fabien LE LEZ writes: | | > Pas dans l'immédiat, en tout cas. | > Surtout après avoir lu les réponses à | > <news:. | > Il est possible qu'à moyen terme je l'utilise, comme il est possible | > que d'autres compilos finissent par l'implémenter. | | Sauf erreur de ma part, le compilateur Intel utilise aussi EDG.
C'est exact. Et ils ont exprès désactivé « export ». Va savoir pourquoi.
La versions la plus recente (sur Linux) la reactive.
David
Jean-Marc Bourguet
(Daveed Vandevoorde) writes:
Pour clarification: Nous etions 3 personnes (Comeau ne fait que recompiler nos sources; je le compte pas dans l'effort d'implementation, bien que jusqu'a recemment c'etait grace a lui que l'implementation etait accessible).
Ne sachant pas exactement ce que vous fournissiez à vos clients, je ne voulais pas ignorer la possibilité qu'ils aient besoin d'un travail significatif (?) pour fournir une implémentation utilisable -- en particulier puisqu'Intel ne l'a pas fourni directement.
L'implementation a pris 1 1/2 ans et pendant cette meme periode nous avons ajoute un mode de compatibilite gcc (e.g., permettant de compiler le kernel Linux): Pas un petit projet non plus.
Non, surtout qu'il devait là dedans avoir des choses encore moins bien définie qu'export je suppose :-)
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
Pour clarification: Nous etions 3 personnes (Comeau ne
fait que recompiler nos sources; je le compte pas dans
l'effort d'implementation, bien que jusqu'a recemment
c'etait grace a lui que l'implementation etait
accessible).
Ne sachant pas exactement ce que vous fournissiez à vos
clients, je ne voulais pas ignorer la possibilité qu'ils
aient besoin d'un travail significatif (?) pour fournir une
implémentation utilisable -- en particulier puisqu'Intel ne
l'a pas fourni directement.
L'implementation a pris 1 1/2 ans et pendant cette meme
periode nous avons ajoute un mode de compatibilite gcc
(e.g., permettant de compiler le kernel Linux): Pas un
petit projet non plus.
Non, surtout qu'il devait là dedans avoir des choses encore
moins bien définie qu'export je suppose :-)
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
Pour clarification: Nous etions 3 personnes (Comeau ne fait que recompiler nos sources; je le compte pas dans l'effort d'implementation, bien que jusqu'a recemment c'etait grace a lui que l'implementation etait accessible).
Ne sachant pas exactement ce que vous fournissiez à vos clients, je ne voulais pas ignorer la possibilité qu'ils aient besoin d'un travail significatif (?) pour fournir une implémentation utilisable -- en particulier puisqu'Intel ne l'a pas fourni directement.
L'implementation a pris 1 1/2 ans et pendant cette meme periode nous avons ajoute un mode de compatibilite gcc (e.g., permettant de compiler le kernel Linux): Pas un petit projet non plus.
Non, surtout qu'il devait là dedans avoir des choses encore moins bien définie qu'export je suppose :-)
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
google
Jean-Marc Bourguet wrote:
Fabien LE LEZ writes:
D'après toi, export aurait une réelle utilité ?
D'après moi, oui. Outre la propreté, il y a un gain certain en vitesse pour les templates instanciés dans plusieurs unités de compilation pour les compilateurs utilisant une méthode itérée d'instantiation.
Dans mon article pour Overload il y a des chiffres sur un exemple artificiel. Pour le batir A partir de scratch: 10.2s sans entête précompilé 5.2s avec 3.7s avec export Après une modification du type: 9.4s, 4.7s et 2.5s Après une modification du template: 9.3s, 4.7s et 2s (J'avais pas fait de mesure en combinant les entêtes précompilés et export à cause d'un bug de como).
Note que como utilise notre (EDG) systeme de reconstruction de context export tres inefficace (on recompile a partir des sources). Un "back end" peut assez facilement le remplacer par une "save/load back end" (semblable au mechanism de precompilation) qui significativement accelerera les nombres export.
David
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
D'après toi, export aurait une réelle utilité ?
D'après moi, oui. Outre la propreté, il y a un gain certain
en vitesse pour les templates instanciés dans plusieurs
unités de compilation pour les compilateurs utilisant une
méthode itérée d'instantiation.
Dans mon article pour Overload il y a des chiffres sur un
exemple artificiel. Pour le batir
A partir de scratch: 10.2s sans entête précompilé
5.2s avec
3.7s avec export
Après une modification du type: 9.4s, 4.7s et 2.5s
Après une modification du template: 9.3s, 4.7s et 2s
(J'avais pas fait de mesure en combinant les entêtes
précompilés et export à cause d'un bug de como).
Note que como utilise notre (EDG) systeme de reconstruction
de context export tres inefficace (on recompile a partir des
sources). Un "back end" peut assez facilement le remplacer
par une "save/load back end" (semblable au mechanism de
precompilation) qui significativement accelerera les nombres
export.
D'après moi, oui. Outre la propreté, il y a un gain certain en vitesse pour les templates instanciés dans plusieurs unités de compilation pour les compilateurs utilisant une méthode itérée d'instantiation.
Dans mon article pour Overload il y a des chiffres sur un exemple artificiel. Pour le batir A partir de scratch: 10.2s sans entête précompilé 5.2s avec 3.7s avec export Après une modification du type: 9.4s, 4.7s et 2.5s Après une modification du template: 9.3s, 4.7s et 2s (J'avais pas fait de mesure en combinant les entêtes précompilés et export à cause d'un bug de como).
Note que como utilise notre (EDG) systeme de reconstruction de context export tres inefficace (on recompile a partir des sources). Un "back end" peut assez facilement le remplacer par une "save/load back end" (semblable au mechanism de precompilation) qui significativement accelerera les nombres export.
