// 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.
| On Wed, 27 Oct 2004 18:27:15 +0200, drkm : | | > Unfortunately, I do not know of any good and safe use for | > std::uncaught_exception. My advice: Don't use it. | | En lisant Herb Sutter, on s'aperçoit qu'un sacré paquet de | fonctionnalités de C++ sont inutiles[*] ;-) | | [*] à commencer par "export", même s'il est moins catégorique sur cet | exemple.
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.
Je ne pense pas que ce soit le cas: Export peut aussi fonctioner (et accelerer) les tactiques "greedy" et "queried". Seulement, si il n'y a pas une etape d'instantiation au "link time", il faut exploiter la provision du standard qui permet d'imposer un ordre de compilation. Cependant, cette etape "link time" peut elle meme utilise les tactique "greedy" ou "queried".
<mode=Parthe> C'est quoi le mécanisme d'instantiation utilisé par Microsoft? </mode=Parthe>
(Je ne comprend pas le mot "Parthe", mais de vais deviner.)
Herb dirige le groupe compilo C++ a Microsoft, mais je ne pense pas que leur strategie d'instantiation est la motivation de la campagne de Herb.
David
Jean-Marc Bourguet <jm@bourguet.org> wrote:
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
Fabien LE LEZ <gramster@gramster.com> writes:
| On Wed, 27 Oct 2004 18:27:15 +0200, drkm <usenet.fclcxx@fgeorges.org>:
|
| > Unfortunately, I do not know of any good and safe use for
| > std::uncaught_exception. My advice: Don't use it.
|
| En lisant Herb Sutter, on s'aperçoit qu'un sacré paquet de
| fonctionnalités de C++ sont inutiles[*] ;-)
|
| [*] à commencer par "export", même s'il est moins catégorique sur cet
| exemple.
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.
Je ne pense pas que ce soit le cas: Export peut aussi fonctioner
(et accelerer) les tactiques "greedy" et "queried". Seulement,
si il n'y a pas une etape d'instantiation au "link time", il faut
exploiter la provision du standard qui permet d'imposer un
ordre de compilation. Cependant, cette etape "link time"
peut elle meme utilise les tactique "greedy" ou "queried".
<mode=Parthe>
C'est quoi le mécanisme d'instantiation utilisé par Microsoft?
</mode=Parthe>
(Je ne comprend pas le mot "Parthe", mais de vais deviner.)
Herb dirige le groupe compilo C++ a Microsoft, mais je ne
pense pas que leur strategie d'instantiation est la motivation
de la campagne de Herb.
| On Wed, 27 Oct 2004 18:27:15 +0200, drkm : | | > Unfortunately, I do not know of any good and safe use for | > std::uncaught_exception. My advice: Don't use it. | | En lisant Herb Sutter, on s'aperçoit qu'un sacré paquet de | fonctionnalités de C++ sont inutiles[*] ;-) | | [*] à commencer par "export", même s'il est moins catégorique sur cet | exemple.
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.
Je ne pense pas que ce soit le cas: Export peut aussi fonctioner (et accelerer) les tactiques "greedy" et "queried". Seulement, si il n'y a pas une etape d'instantiation au "link time", il faut exploiter la provision du standard qui permet d'imposer un ordre de compilation. Cependant, cette etape "link time" peut elle meme utilise les tactique "greedy" ou "queried".
<mode=Parthe> C'est quoi le mécanisme d'instantiation utilisé par Microsoft? </mode=Parthe>
(Je ne comprend pas le mot "Parthe", mais de vais deviner.)
Herb dirige le groupe compilo C++ a Microsoft, mais je ne pense pas que leur strategie d'instantiation est la motivation de la campagne de Herb.
David
Jean-Marc Bourguet
(Daveed Vandevoorde) writes:
Herb dirige le groupe compilo C++ a Microsoft, mais je ne pense pas que leur strategie d'instantiation est la motivation de la campagne de Herb.
Tu as une idée sur sa motivation?
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
Herb dirige le groupe compilo C++ a Microsoft, mais je ne
pense pas que leur strategie d'instantiation est la
motivation de la campagne de Herb.
Tu as une idée sur sa motivation?
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
Herb dirige le groupe compilo C++ a Microsoft, mais je ne pense pas que leur strategie d'instantiation est la motivation de la campagne de Herb.
Tu as une idée sur sa motivation?
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
(Daveed Vandevoorde) writes:
| 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.
| Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
| > Matthieu Moy <MatthieuNOSPAM.Moy@imag.fr.invalid> writes:
| >
| > | 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.
| 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.
Wee!
OK, la balle est dans le camp de GCC.
-- Gaby
Gabriel Dos Reis
Jean-Marc Bourguet writes:
[...]
| > 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 :-)
Oui, là on rentre dans de la programmation quantique :-) :-)
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > 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 :-)
Oui, là on rentre dans de la programmation quantique :-) :-)
| > 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 :-)
Oui, là on rentre dans de la programmation quantique :-) :-)
-- Gaby
Gabriel Dos Reis
Fabien LE LEZ writes:
| 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 ?
Bah, fais un google :-)
-- Gaby
Fabien LE LEZ <gramster@gramster.com> writes:
| On 29 Oct 2004 08:24:57 -0700, google@vandevoorde.com (Daveed
| Vandevoorde):
|
| >J'ai essaye a plusiers fois de
| >convaincre Herb des erreures techniques (grossieres, malheureusement)
| >dans ce chapitre
|
| Quelles sont-elles ?
| 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 ?
Bah, fais un google :-)
-- Gaby
google
Fabien LE LEZ wrote in message news:...
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 ?
La separation protege contre l'interference d'autres declarations (les macros en particuliers).
Pour certains, la possibilite de distribuer des definition templates en forme binaire est attrayant aussi.
Mais il y aussi un aspet intangible qui resulte d'export. La possibilite de separer mes templates de la meme facon que mes non-template est simplement agreable. Peut-etre que c'est juste moi, mais chaque fois que j'ecrit de petits modules avec export j'aspire a pouvoir coder de la meme facon avec d'autres compilos.
David
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<ugo4o0hm2462gmtqv52agh29jv726r52r2@4ax.com>...
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 ?
La separation protege contre l'interference d'autres declarations
(les macros en particuliers).
Pour certains, la possibilite de distribuer des definition templates
en forme binaire est attrayant aussi.
Mais il y aussi un aspet intangible qui resulte d'export. La possibilite
de separer mes templates de la meme facon que mes non-template
est simplement agreable. Peut-etre que c'est juste moi, mais chaque
fois que j'ecrit de petits modules avec export j'aspire a pouvoir coder
de la meme facon avec d'autres compilos.
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 ?
La separation protege contre l'interference d'autres declarations (les macros en particuliers).
Pour certains, la possibilite de distribuer des definition templates en forme binaire est attrayant aussi.
Mais il y aussi un aspet intangible qui resulte d'export. La possibilite de separer mes templates de la meme facon que mes non-template est simplement agreable. Peut-etre que c'est juste moi, mais chaque fois que j'ecrit de petits modules avec export j'aspire a pouvoir coder de la meme facon avec d'autres compilos.
David
google
Fabien LE LEZ wrote in message news:...
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 ?
Je n'ai pas vraiment le temps de traverser les deux items (9 & 10) dans son bouquin, mais voici quelques notes:
- Il pretend que export implique que le code source doit etre present a l'instantiation. C'est incorrecte. Il essaye de justifier sa position avec un longue explication de "template definition context" mais il ne comprends pas vraiment comment marche des tables de symboles dans les compilos C++ modernes et donc ne comprends pas qu'en fait il n'y pas de problemes technique majeure ici. C'est vrai qu'au moment d'une instantiation il y un peu plus de travaille que les "fixups" necessaire pour les non-templates, mais ce travaille demeure neanmoins minuscule compare a la compilation du template meme. - Il pretend que les "dependences" sont les memes pour export que pour les templates inclues. C'est incorrecte. - Il pretend qu'en 1995-1996 seulement un compilo commercial pouvait compiler l'STL original. En fait il y en avait au moins une demi douzaine et probablement plus. Il utilise ca comme argument pour dire que le committe ne comprenait pas ce qu'il faisait a cette epoque. En fait, tout les problemes d'implementation d'export qu'on a rencontre en 2002 avait ete mentionne en 1996. Il n'y avait donc pas de surprises. - Il attribue la complexite d'export premierement a "Koenig lookup." Ca n'a pas ete notre experience: Nous avions deja cette forme de "lookup" et la generalization pour plusieurs "translation units" a pris moins d'un jour de travail. - ...
A part ces erreurs, il y aussi des remarques qui dramatisent des aspets d'export qui ne sont vraiment pas un probleme. Par example, il est vrai que si un template export appelle une fonction dans un "unnamed namespace", cette fonction en pratique serat appele d'un fichier objet qui n'est pas directement associe au template. Mais pourquoi est-ce un probleme? C'est en fait un detail d'implementation pas neuf. Meme un simple fonction en-ligne inline int f(int i) { static int l = i; return l; } force un compilo de promouvoir une variable tres locale pour access public du point de vue "linker".
Il y plein de trucs comme ca dans ces articles.
David
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<jlo4o0hb0udcdnb8l9904gcsb7ht3cj7kb@4ax.com>...
On 29 Oct 2004 08:24:57 -0700, google@vandevoorde.com (Daveed
Vandevoorde):
J'ai essaye a plusiers fois de
convaincre Herb des erreures techniques (grossieres, malheureusement)
dans ce chapitre
Quelles sont-elles ?
Je n'ai pas vraiment le temps de traverser les deux items (9 & 10)
dans son bouquin, mais voici quelques notes:
- Il pretend que export implique que le code source doit etre
present a l'instantiation. C'est incorrecte. Il essaye de justifier
sa position avec un longue explication de "template definition
context" mais il ne comprends pas vraiment comment marche
des tables de symboles dans les compilos C++ modernes et
donc ne comprends pas qu'en fait il n'y pas de problemes
technique majeure ici. C'est vrai qu'au moment d'une instantiation
il y un peu plus de travaille que les "fixups" necessaire pour les
non-templates, mais ce travaille demeure neanmoins minuscule
compare a la compilation du template meme.
- Il pretend que les "dependences" sont les memes pour export
que pour les templates inclues. C'est incorrecte.
- Il pretend qu'en 1995-1996 seulement un compilo commercial
pouvait compiler l'STL original. En fait il y en avait au moins une
demi douzaine et probablement plus. Il utilise ca comme argument
pour dire que le committe ne comprenait pas ce qu'il faisait a cette
epoque. En fait, tout les problemes d'implementation d'export qu'on
a rencontre en 2002 avait ete mentionne en 1996. Il n'y avait donc
pas de surprises.
- Il attribue la complexite d'export premierement a "Koenig lookup."
Ca n'a pas ete notre experience: Nous avions deja cette forme de
"lookup" et la generalization pour plusieurs "translation units"
a pris moins d'un jour de travail.
- ...
A part ces erreurs, il y aussi des remarques qui dramatisent des aspets
d'export qui ne sont vraiment pas un probleme. Par example, il est
vrai que si un template export appelle une fonction dans un "unnamed
namespace", cette fonction en pratique serat appele d'un fichier objet
qui n'est pas directement associe au template. Mais pourquoi est-ce
un probleme? C'est en fait un detail d'implementation pas neuf.
Meme un simple fonction en-ligne
inline int f(int i) {
static int l = i;
return l;
}
force un compilo de promouvoir une variable tres locale pour access
public du point de vue "linker".
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 ?
Je n'ai pas vraiment le temps de traverser les deux items (9 & 10) dans son bouquin, mais voici quelques notes:
- Il pretend que export implique que le code source doit etre present a l'instantiation. C'est incorrecte. Il essaye de justifier sa position avec un longue explication de "template definition context" mais il ne comprends pas vraiment comment marche des tables de symboles dans les compilos C++ modernes et donc ne comprends pas qu'en fait il n'y pas de problemes technique majeure ici. C'est vrai qu'au moment d'une instantiation il y un peu plus de travaille que les "fixups" necessaire pour les non-templates, mais ce travaille demeure neanmoins minuscule compare a la compilation du template meme. - Il pretend que les "dependences" sont les memes pour export que pour les templates inclues. C'est incorrecte. - Il pretend qu'en 1995-1996 seulement un compilo commercial pouvait compiler l'STL original. En fait il y en avait au moins une demi douzaine et probablement plus. Il utilise ca comme argument pour dire que le committe ne comprenait pas ce qu'il faisait a cette epoque. En fait, tout les problemes d'implementation d'export qu'on a rencontre en 2002 avait ete mentionne en 1996. Il n'y avait donc pas de surprises. - Il attribue la complexite d'export premierement a "Koenig lookup." Ca n'a pas ete notre experience: Nous avions deja cette forme de "lookup" et la generalization pour plusieurs "translation units" a pris moins d'un jour de travail. - ...
A part ces erreurs, il y aussi des remarques qui dramatisent des aspets d'export qui ne sont vraiment pas un probleme. Par example, il est vrai que si un template export appelle une fonction dans un "unnamed namespace", cette fonction en pratique serat appele d'un fichier objet qui n'est pas directement associe au template. Mais pourquoi est-ce un probleme? C'est en fait un detail d'implementation pas neuf. Meme un simple fonction en-ligne inline int f(int i) { static int l = i; return l; } force un compilo de promouvoir une variable tres locale pour access public du point de vue "linker".
Il y plein de trucs comme ca dans ces articles.
David
drkm
(Daveed Vandevoorde) writes:
[critique intéressante]
- Il pretend que les "dependences" sont les memes pour export que pour les templates inclues. C'est incorrecte.
De quelles dépendences parles-tu ? Peux-tu donner l'une ou l'autre différence, ou une URL ou une référence dans la norme énonçant ces différences ?
- Il pretend que les "dependences" sont les memes pour export que pour les templates inclues. C'est incorrecte.
De quelles dépendences parles-tu ? Peux-tu donner l'une ou l'autre différence, ou une URL ou une référence dans la norme énonçant ces différences ?
Merci.
--drkm
Jean-Marc Bourguet
Jean-Marc Bourguet writes:
Gabriel Dos Reis writes:
Pour ce qu'il est censé faire, oui. Tu voudras peut-être lire l'article de Jean-Marc dans Overload.
Je vais essayer de voir si je peux le mettre sur mon site.
Je suis bien toujours le détenteur des droits. Le voici:
http://www.bourguet.org/cpp/export.pdf
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
Jean-Marc Bourguet <jm@bourguet.org> writes:
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
Pour ce qu'il est censé faire, oui. Tu voudras peut-être lire l'article
de Jean-Marc dans Overload.
Je vais essayer de voir si je peux le mettre sur mon site.
Je suis bien toujours le détenteur des droits. Le voici:
http://www.bourguet.org/cpp/export.pdf
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 ce qu'il est censé faire, oui. Tu voudras peut-être lire l'article de Jean-Marc dans Overload.
Je vais essayer de voir si je peux le mettre sur mon site.
Je suis bien toujours le détenteur des droits. Le voici:
http://www.bourguet.org/cpp/export.pdf
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
James Kanze
Gabriel Dos Reis writes:
|> Jean-Marc Bourguet writes:
[...] |> | 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 » ?
Ça dépend des raisons qu'il en donne. Dans le travail, moi aussi, je conseille d'éviter export. Écrire du code qu'on ne peut pas compiler avec Sun CC, qu'on ne peut pas compiler avec g++ et qu'on ne peut pas compiler avec VC++, c'est d'écrire du code inutilisable (chez nous).
Je suis donc obligé à dire qu'on ne doit pas utiliser export. Malheureusement, parce que tout ce que j'en lis des gens qui s'en sont servi, ou qui le connaissent, me donne encore plus envie de l'utiliser.
Si Herb dit qu'il ne faut pas utiliser export à cause des risques de portabilité, je ne peux qu'être d'accord. S'il prétend donner d'autres raisons, je suis plus scéptique. Ne serait-ce que parce que je me démande comment il pourrait savoir -- à la fin, la vraie importance ne se détermine que d'après expérience, et je crois que je ne risque rien en supposant qu'il n'y a pas beaucoup de grands projets aujourd'hui qui ont fait une utilisation importante d'export.
|> | <mode=Parthe> |> | C'est quoi le mécanisme d'instantiation utilisé par Microsoft? |> | </mode=Parthe>
|> Je ne sais pas.
Je *crois* que c'est greedy, mais je ne me mettrais pas ma main au feu.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
|> Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
|> | 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 » ?
Ça dépend des raisons qu'il en donne. Dans le travail, moi aussi, je
conseille d'éviter export. Écrire du code qu'on ne peut pas compiler
avec Sun CC, qu'on ne peut pas compiler avec g++ et qu'on ne peut pas
compiler avec VC++, c'est d'écrire du code inutilisable (chez nous).
Je suis donc obligé à dire qu'on ne doit pas utiliser export.
Malheureusement, parce que tout ce que j'en lis des gens qui s'en sont
servi, ou qui le connaissent, me donne encore plus envie de l'utiliser.
Si Herb dit qu'il ne faut pas utiliser export à cause des risques de
portabilité, je ne peux qu'être d'accord. S'il prétend donner d'autres
raisons, je suis plus scéptique. Ne serait-ce que parce que je me
démande comment il pourrait savoir -- à la fin, la vraie importance ne
se détermine que d'après expérience, et je crois que je ne risque rien
en supposant qu'il n'y a pas beaucoup de grands projets aujourd'hui qui
ont fait une utilisation importante d'export.
|> | <mode=Parthe>
|> | C'est quoi le mécanisme d'instantiation utilisé par Microsoft?
|> | </mode=Parthe>
|> Je ne sais pas.
Je *crois* que c'est greedy, mais je ne me mettrais pas ma main au feu.
--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
[...] |> | 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 » ?
Ça dépend des raisons qu'il en donne. Dans le travail, moi aussi, je conseille d'éviter export. Écrire du code qu'on ne peut pas compiler avec Sun CC, qu'on ne peut pas compiler avec g++ et qu'on ne peut pas compiler avec VC++, c'est d'écrire du code inutilisable (chez nous).
Je suis donc obligé à dire qu'on ne doit pas utiliser export. Malheureusement, parce que tout ce que j'en lis des gens qui s'en sont servi, ou qui le connaissent, me donne encore plus envie de l'utiliser.
Si Herb dit qu'il ne faut pas utiliser export à cause des risques de portabilité, je ne peux qu'être d'accord. S'il prétend donner d'autres raisons, je suis plus scéptique. Ne serait-ce que parce que je me démande comment il pourrait savoir -- à la fin, la vraie importance ne se détermine que d'après expérience, et je crois que je ne risque rien en supposant qu'il n'y a pas beaucoup de grands projets aujourd'hui qui ont fait une utilisation importante d'export.
|> | <mode=Parthe> |> | C'est quoi le mécanisme d'instantiation utilisé par Microsoft? |> | </mode=Parthe>
|> Je ne sais pas.
Je *crois* que c'est greedy, mais je ne me mettrais pas ma main au feu.
-- James Kanze Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
