A mon niveau je vois juste les namespaces un peut comme des "librairies"
pour pouvoir organiser les objets et éviter les collisions (bon terme?).
fondamentalement je ne vois pas trop la différence entre utiliser un
namespace qui contiendrait un objet déclaré static et utiliser une
classe de type singleton ayant leur instance globale ...
les namespaces sont t'il chargés/déchargés quand il y en a
besoin/plus besoin ?
Est-ce que ça coûte plus cher en CPU/RAM d'utiliser un objet à
déclaré à l'interieur d'un namespace plutôt qu'à un objet du même
type déclaré en dehors ?
Sinon comment fait-on pour importer, dans un namespace A des classes
(implémentées dans d'autres fichiers) et faire en sorte que ces classes
ne puissent pas être visibles/utilisés directement ailleurs dans le code
(sans passer par le namespace N) ?
faut t'il obligatoirement en faire une librairie ?
(j'ai tenté des trucs vite fait avec extern mais ça ne compilait pas)
Pareil pour les namespaces, faut t'il obligatoirement quelque chose
comme :
//.h :
namespace A {
int MA();
namespace B { int MB(); }
}
//.cpp(s)
int A::mA() { return 1; }
int A::B::MB() { return 2; }
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur 7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai: le contexte n'est visiblement pas celui pour lequel la règle a été écrite.
Mon point était tout autre: même dans les contextes où les gardes externes gagnent quelque chose, je ne les ai jamais vu conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs pas si James le faisait en connaissance de cause où réagissait simplement au message de Fabien en ayant oublié cette partie du contexte.
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
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message 87fyyrsbhi.fsf@news.bourguet.org,
Je viens d'aller voir, Laklos ne conseille les gardes
externes que dans les en-têtes, pas dans le code.
Par contre, dans le (beaucoup plus récent) livre de Sutter et
Alexandrescu (C++ Coding Standards: 101 Rules, Guidelines,
and Best Practices) :
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais
Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un
facteur 7, quoi qu'en disent Sutter et Alexandrescu je
l'emploierai: le contexte n'est visiblement pas celui pour
lequel la règle a été écrite.
Mon point était tout autre: même dans les contextes où les
gardes externes gagnent quelque chose, je ne les ai jamais
vu conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs
pas si James le faisait en connaissance de cause où
réagissait simplement au message de Fabien en ayant oublié
cette partie du contexte.
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
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur 7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai: le contexte n'est visiblement pas celui pour lequel la règle a été écrite.
Mon point était tout autre: même dans les contextes où les gardes externes gagnent quelque chose, je ne les ai jamais vu conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs pas si James le faisait en connaissance de cause où réagissait simplement au message de Fabien en ayant oublié cette partie du contexte.
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
Fabien LE LEZ wrote:
On Sat, 19 Mar 2005 17:47:06 +0100, James Kanze :
a fait passer le temps d'un build complète de 28 heures à 4 heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'était à peu près une million de lignes ; je ne sais pas combien de fichiers.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Sat, 19 Mar 2005 17:47:06 +0100, James Kanze <kanze@none>:
a fait passer le temps d'un build complète de 28 heures à 4
heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'était à peu près une million de lignes ; je ne sais pas
combien de fichiers.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
a fait passer le temps d'un build complète de 28 heures à 4 heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'était à peu près une million de lignes ; je ne sais pas combien de fichiers.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Jean-Marc Bourguet wrote:
James Kanze writes:
Je ne vois pas l'intérêt du "#ifndef" ici -- ça alourdit le code, et c'est inutile puisqu'il y a déjà un "#ifndef" au début du .h.
Ça peut jouer énormement sur les temps de compilation. Dans un projet, l'ajoute des #ifndef autour de l'include a fait passer le temps d'un build complète de 28 heures à 4 heures.
L'ajout de gardes externes dans les .cpp a divisé par 7 le temps de compilation? J'ai des doutes. Je comprends que les gardes externes dans les en-têtes peuvent éviter un comportement quadratique, mais dans les .cpp je doute qu'ils aient à eux seuls un effet aussi important.
Je viens d'aller voir, Laklos ne conseille les gardes externes que dans les en-têtes, pas dans le code.
Je me suis mal exprimé. Les gardes, on les a mis autour de tous les include (sauf les include système, où on ne maîtrisait pas les conventions du nommage de la garde), que ce soit les .cc ou les .hh.
Les résultats varient, évidemment. À l'époque, Steve Clamage parlait des mésures où ils ne trouvent pas de différence. Vraisembableemnt avec le même compilateur (Sun CC). Je ne sais pas à quoi c'était dû ; ce que je sais, c'est que dans notre cas, la quantité des include était assez grande qu'il n'y avait aucune chance que le système les rétrouver dans sa cache, et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
James Kanze <kanze@none> writes:
Je ne vois pas l'intérêt du "#ifndef" ici -- ça alourdit le
code, et c'est inutile puisqu'il y a déjà un "#ifndef" au
début du .h.
Ça peut jouer énormement sur les temps de compilation. Dans un
projet, l'ajoute des #ifndef autour de l'include a fait passer
le temps d'un build complète de 28 heures à 4 heures.
L'ajout de gardes externes dans les .cpp a divisé par 7 le
temps de compilation? J'ai des doutes. Je comprends que les
gardes externes dans les en-têtes peuvent éviter un
comportement quadratique, mais dans les .cpp je doute qu'ils
aient à eux seuls un effet aussi important.
Je viens d'aller voir, Laklos ne conseille les gardes
externes que dans les en-têtes, pas dans le code.
Je me suis mal exprimé. Les gardes, on les a mis autour de tous
les include (sauf les include système, où on ne maîtrisait pas
les conventions du nommage de la garde), que ce soit les .cc ou
les .hh.
Les résultats varient, évidemment. À l'époque, Steve Clamage
parlait des mésures où ils ne trouvent pas de différence.
Vraisembableemnt avec le même compilateur (Sun CC). Je ne sais
pas à quoi c'était dû ; ce que je sais, c'est que dans notre
cas, la quantité des include était assez grande qu'il n'y avait
aucune chance que le système les rétrouver dans sa cache, et
que la plupart du temps, la majorité des includes se trouvaient
sur une autre machine, et qu'on les lisait à travers un reseau
10 M-baud.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Je ne vois pas l'intérêt du "#ifndef" ici -- ça alourdit le code, et c'est inutile puisqu'il y a déjà un "#ifndef" au début du .h.
Ça peut jouer énormement sur les temps de compilation. Dans un projet, l'ajoute des #ifndef autour de l'include a fait passer le temps d'un build complète de 28 heures à 4 heures.
L'ajout de gardes externes dans les .cpp a divisé par 7 le temps de compilation? J'ai des doutes. Je comprends que les gardes externes dans les en-têtes peuvent éviter un comportement quadratique, mais dans les .cpp je doute qu'ils aient à eux seuls un effet aussi important.
Je viens d'aller voir, Laklos ne conseille les gardes externes que dans les en-têtes, pas dans le code.
Je me suis mal exprimé. Les gardes, on les a mis autour de tous les include (sauf les include système, où on ne maîtrisait pas les conventions du nommage de la garde), que ce soit les .cc ou les .hh.
Les résultats varient, évidemment. À l'époque, Steve Clamage parlait des mésures où ils ne trouvent pas de différence. Vraisembableemnt avec le même compilateur (Sun CC). Je ne sais pas à quoi c'était dû ; ce que je sais, c'est que dans notre cas, la quantité des include était assez grande qu'il n'y avait aucune chance que le système les rétrouver dans sa cache, et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
James Kanze
Jean-Marc Bourguet wrote:
"Michel Michaud" writes:
Dans le message ,
Je viens d'aller voir, Laklos ne conseille les gardes externes que dans les en-têtes, pas dans le code.
Par contre, dans le (beaucoup plus récent) livre de Sutter et Alexandrescu (C++ Coding Standards: 101 Rules, Guidelines, and Best Practices) :
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur 7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai: le contexte n'est visiblement pas celui pour lequel la règle a été écrite.
Ça dépend. Dans notre cas, il s'agissait de builder quatre versions du système. Sans les gardes extérieur, un week-end ne suffisait pas. Alors...
Mais passer de 700 millisecondes à 100 millisecondes est aussi une facteur de 7:-).
Mon point était tout autre: même dans les contextes où les gardes externes gagnent quelque chose, je ne les ai jamais vu conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs pas si James le faisait en connaissance de cause où réagissait simplement au message de Fabien en ayant oublié cette partie du contexte.
Je racontais une expérience réele, c'est tout. Mes derniers projets ont été plus petits ; alors, que des gardes intérnes.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Jean-Marc Bourguet wrote:
"Michel Michaud" <mm@gdzid.com> writes:
Dans le message 87fyyrsbhi.fsf@news.bourguet.org,
Je viens d'aller voir, Laklos ne conseille les gardes
externes que dans les en-têtes, pas dans le code.
Par contre, dans le (beaucoup plus récent) livre de Sutter et
Alexandrescu (C++ Coding Standards: 101 Rules, Guidelines, and
Best Practices) :
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais
Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur
7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai:
le contexte n'est visiblement pas celui pour lequel la règle a
été écrite.
Ça dépend. Dans notre cas, il s'agissait de builder quatre
versions du système. Sans les gardes extérieur, un week-end ne
suffisait pas. Alors...
Mais passer de 700 millisecondes à 100 millisecondes est aussi
une facteur de 7:-).
Mon point était tout autre: même dans les contextes où les
gardes externes gagnent quelque chose, je ne les ai jamais vu
conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs pas si
James le faisait en connaissance de cause où réagissait
simplement au message de Fabien en ayant oublié cette partie
du contexte.
Je racontais une expérience réele, c'est tout. Mes derniers
projets ont été plus petits ; alors, que des gardes intérnes.
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur 7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai: le contexte n'est visiblement pas celui pour lequel la règle a été écrite.
Ça dépend. Dans notre cas, il s'agissait de builder quatre versions du système. Sans les gardes extérieur, un week-end ne suffisait pas. Alors...
Mais passer de 700 millisecondes à 100 millisecondes est aussi une facteur de 7:-).
Mon point était tout autre: même dans les contextes où les gardes externes gagnent quelque chose, je ne les ai jamais vu conseillé à l'intérieur de .cpp. Je ne sais d'ailleurs pas si James le faisait en connaissance de cause où réagissait simplement au message de Fabien en ayant oublié cette partie du contexte.
Je racontais une expérience réele, c'est tout. Mes derniers projets ont été plus petits ; alors, que des gardes intérnes.
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Matthieu Moy
Fabien LE LEZ writes:
On Sat, 19 Mar 2005 17:47:06 +0100, James Kanze :
a fait passer le temps d'un build complète de 28 heures à 4 heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'est a peu près le temps de compil de OpenOffice.org sur mon P433 par exemple. (28h, pas 4 ...)
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
On Sat, 19 Mar 2005 17:47:06 +0100, James Kanze <kanze@none>:
a fait passer
le temps d'un build complète de 28 heures à 4 heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'est a peu près le temps de compil de OpenOffice.org sur mon P433 par
exemple. (28h, pas 4 ...)
a fait passer le temps d'un build complète de 28 heures à 4 heures
Un tel projet, c'est combien de fichiers / lignes de codes ?
C'est a peu près le temps de compil de OpenOffice.org sur mon P433 par exemple. (28h, pas 4 ...)
-- Matthieu
Fabien LE LEZ
On Mon, 21 Mar 2005 00:06:50 +0100, James Kanze :
et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
Arf... Évidemment, ça aide pas... Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
-- ;-)
On Mon, 21 Mar 2005 00:06:50 +0100, James Kanze <kanze@none>:
et
que la plupart du temps, la majorité des includes se trouvaient
sur une autre machine, et qu'on les lisait à travers un reseau
10 M-baud.
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque machine
chargée de compiler, aurait accéléré la compilation encore plus qu'en
utilisant des gardes externes ?..
et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
Arf... Évidemment, ça aide pas... Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
-- ;-)
Matthieu Moy
Fabien LE LEZ writes:
Arf... Évidemment, ça aide pas... Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de preprocessing, et en principe, le preprocessing prends moins de temps que le reste de la compilation. Un gain de quelques dizaines de pourcents ne m'étonnerait pas trop, mais un facteur 7, c'est qu'il y a un problème quelque part ...
-- Matthieu
Fabien LE LEZ <gramster@gramster.com> writes:
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque machine
chargée de compiler, aurait accéléré la compilation encore plus qu'en
utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de
preprocessing, et en principe, le preprocessing prends moins de temps
que le reste de la compilation. Un gain de quelques dizaines de
pourcents ne m'étonnerait pas trop, mais un facteur 7, c'est qu'il y a
un problème quelque part ...
Arf... Évidemment, ça aide pas... Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de preprocessing, et en principe, le preprocessing prends moins de temps que le reste de la compilation. Un gain de quelques dizaines de pourcents ne m'étonnerait pas trop, mais un facteur 7, c'est qu'il y a un problème quelque part ...
-- Matthieu
Michel Michaud
Dans le message ,
"Michel Michaud" writes:
Par contre, dans le (beaucoup plus récent) livre de Sutter et Alexandrescu (C++ Coding Standards: 101 Rules, Guidelines, and Best Practices) :
Je n'ai pas encore le livre, alors je ne peux en dire plus. Mais Lakos commence à être vieux...
Si quelque chose réduit le temps de compilation par un facteur 7, quoi qu'en disent Sutter et Alexandrescu je l'emploierai:
Effectivement moi aussi. Mais j'imagine que Sutter et Alexandrescu aussi, sauf s'il y a un problème d'un autre niveau.
le contexte n'est visiblement pas celui pour lequel la règle a été écrite.
Et c'est là qu'est peut-être un problème qui nous échappe. Il faudrait que quelqu'un qui a le livre puisse en parler, nous ne le pouvons pas...
-- Michel Michaud http://www.gdzid.com FAQ de fr.comp.lang.c++ : http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ/
kanze
Fabien LE LEZ wrote:
On Mon, 21 Mar 2005 00:06:50 +0100, James Kanze :
et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Tiens, ç'aurait été une idée, au moins au début. En fait, on s'arrangait bien pour que les link se faisait sur le serveur où se trouvaient les lib's.
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Mon, 21 Mar 2005 00:06:50 +0100, James Kanze <kanze@none>:
et que la plupart du temps, la majorité des includes se
trouvaient sur une autre machine, et qu'on les lisait à
travers un reseau 10 M-baud.
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque
machine chargée de compiler, aurait accéléré la compilation
encore plus qu'en utilisant des gardes externes ?..
Tiens, ç'aurait été une idée, au moins au début. En fait, on
s'arrangait bien pour que les link se faisait sur le serveur où
se trouvaient les lib's.
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des
machines sur le reseau n'avaientt pas de disque local.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
et que la plupart du temps, la majorité des includes se trouvaient sur une autre machine, et qu'on les lisait à travers un reseau 10 M-baud.
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Tiens, ç'aurait été une idée, au moins au début. En fait, on s'arrangait bien pour que les link se faisait sur le serveur où se trouvaient les lib's.
Ceci dit, il faut se rappelait qu'à l'époque, la plupart des machines sur le reseau n'avaientt pas de disque local.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Matthieu Moy wrote:
Fabien LE LEZ writes:
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de preprocessing, et en principe, le preprocessing prends moins de temps que le reste de la compilation. Un gain de quelques dizaines de pourcents ne m'étonnerait pas trop, mais un facteur 7, c'est qu'il y a un problème quelque part ...
Le savoir traditionnel dit que l'évalutation lexique du programme coûte bien plus que la moitié des temps de compilation. Évidemment, le savoir traditionnel s'est établi avant les templates et des optimisations puissantes -- avec du C K&R, compilait d'une façon un peu naïf (selon ce auquel on est habitué d'aujourd'hui), le préprocesseur pouvait bien en faire entre 60% et 75% du temps de l'exécution.
Les temps changent ; à l'époque où j'ai eu cette expérience, on se servait pas encore des templates, et l'optimisation était plutôt primitive. Je ne sais pas ce qu'il en serait aujourd'hui.
Ce que je sais, c'est que j'adopterai un standard pour les noms de garde assez tôt dans le projet, et j'insisterais qu'on l'applique de façon très rigueureux. De cette façon, si par la suite, des temps de build devenait un problème, et qu'il apparaît que c'était peut-être à cause de l'évaluation multiple des en-têtes (c'est en fait l'open qui coûte le plus cher), on pourrait facilement ajouter des gardes externes au moyen d'un script assez simple.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Matthieu Moy wrote:
Fabien LE LEZ <gramster@gramster.com> writes:
Arf... Évidemment, ça aide pas...
Peut-être que télécharger tous les headers sur la/chaque
machine chargée de compiler, aurait accéléré la compilation
encore plus qu'en utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de
preprocessing, et en principe, le preprocessing prends moins
de temps que le reste de la compilation. Un gain de quelques
dizaines de pourcents ne m'étonnerait pas trop, mais un
facteur 7, c'est qu'il y a un problème quelque part ...
Le savoir traditionnel dit que l'évalutation lexique du
programme coûte bien plus que la moitié des temps de
compilation. Évidemment, le savoir traditionnel s'est établi
avant les templates et des optimisations puissantes -- avec du C
K&R, compilait d'une façon un peu naïf (selon ce auquel on est
habitué d'aujourd'hui), le préprocesseur pouvait bien en faire
entre 60% et 75% du temps de l'exécution.
Les temps changent ; à l'époque où j'ai eu cette expérience, on
se servait pas encore des templates, et l'optimisation était
plutôt primitive. Je ne sais pas ce qu'il en serait aujourd'hui.
Ce que je sais, c'est que j'adopterai un standard pour les noms
de garde assez tôt dans le projet, et j'insisterais qu'on
l'applique de façon très rigueureux. De cette façon, si par la
suite, des temps de build devenait un problème, et qu'il
apparaît que c'était peut-être à cause de l'évaluation multiple
des en-têtes (c'est en fait l'open qui coûte le plus cher), on
pourrait facilement ajouter des gardes externes au moyen d'un
script assez simple.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Peut-être que télécharger tous les headers sur la/chaque machine chargée de compiler, aurait accéléré la compilation encore plus qu'en utilisant des gardes externes ?..
Probablement. Les gardes externes ne changent que le temps de preprocessing, et en principe, le preprocessing prends moins de temps que le reste de la compilation. Un gain de quelques dizaines de pourcents ne m'étonnerait pas trop, mais un facteur 7, c'est qu'il y a un problème quelque part ...
Le savoir traditionnel dit que l'évalutation lexique du programme coûte bien plus que la moitié des temps de compilation. Évidemment, le savoir traditionnel s'est établi avant les templates et des optimisations puissantes -- avec du C K&R, compilait d'une façon un peu naïf (selon ce auquel on est habitué d'aujourd'hui), le préprocesseur pouvait bien en faire entre 60% et 75% du temps de l'exécution.
Les temps changent ; à l'époque où j'ai eu cette expérience, on se servait pas encore des templates, et l'optimisation était plutôt primitive. Je ne sais pas ce qu'il en serait aujourd'hui.
Ce que je sais, c'est que j'adopterai un standard pour les noms de garde assez tôt dans le projet, et j'insisterais qu'on l'applique de façon très rigueureux. De cette façon, si par la suite, des temps de build devenait un problème, et qu'il apparaît que c'était peut-être à cause de l'évaluation multiple des en-têtes (c'est en fait l'open qui coûte le plus cher), on pourrait facilement ajouter des gardes externes au moyen d'un script assez simple.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
