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; }
le préprocesseur pouvait bien en faire entre 60% et 75% du temps de l'exécution.
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus). Bien sur, entre temps, tu gagnes entre la lexico du preprocesseur et celle de la compilation, ce sont les commentaires et les blocs #if ... #endif qui ont sauté.
Maintenant, je me fiche pas mal de ce que dit le savoir traditionnel, a partir du moment ou l'expérimentation dit que le préprocessing prends a peu près 10% du temps sur ma machine (même sans optimiser).
-- Matthieu
kanze@gabi-soft.fr writes:
le préprocesseur pouvait bien en faire
entre 60% et 75% du temps de l'exécution.
Sauf que l'analyse lexicographique, il faut la refaire pendant la
compilation en elle même, du moins avec g++ qui utilise des processus
séparés pour le préprocesseur (cpp) et la compilation (cc1plus). Bien
sur, entre temps, tu gagnes entre la lexico du preprocesseur et celle
de la compilation, ce sont les commentaires et les blocs #if ...
#endif qui ont sauté.
Maintenant, je me fiche pas mal de ce que dit le savoir traditionnel,
a partir du moment ou l'expérimentation dit que le préprocessing
prends a peu près 10% du temps sur ma machine (même sans optimiser).
le préprocesseur pouvait bien en faire entre 60% et 75% du temps de l'exécution.
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus). Bien sur, entre temps, tu gagnes entre la lexico du preprocesseur et celle de la compilation, ce sont les commentaires et les blocs #if ... #endif qui ont sauté.
Maintenant, je me fiche pas mal de ce que dit le savoir traditionnel, a partir du moment ou l'expérimentation dit que le préprocessing prends a peu près 10% du temps sur ma machine (même sans optimiser).
-- Matthieu
Falk Tannhäuser
Matthieu Moy wrote:
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
J'ai cru comprendre que ceci n'était plus le cas pour les versions plus récentes de gcc.
Falk
Matthieu Moy wrote:
Sauf que l'analyse lexicographique, il faut la refaire pendant la
compilation en elle même, du moins avec g++ qui utilise des processus
séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
J'ai cru comprendre que ceci n'était plus le cas pour les versions
plus récentes de gcc.
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
J'ai cru comprendre que ceci n'était plus le cas pour les versions plus récentes de gcc.
Falk
Jean-Marc Bourguet
Matthieu Moy writes:
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 probleme est l'ouverture du fichier. S'il faut aller le chercher sur le reseau ca peut etre long. De plus, au pire, on peut arriver a des organisations ou le nombre d'ouvertures peut etre le carre du nombre de fichier. L'idee date du temps des reseaux a 10MB, des machines sans disques, et de compilateurs sans en-tetes precompiles.
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
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 probleme est l'ouverture du fichier. S'il faut aller le chercher
sur le reseau ca peut etre long. De plus, au pire, on peut arriver a
des organisations ou le nombre d'ouvertures peut etre le carre du
nombre de fichier. L'idee date du temps des reseaux a 10MB, des
machines sans disques, et de compilateurs sans en-tetes precompiles.
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
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 probleme est l'ouverture du fichier. S'il faut aller le chercher sur le reseau ca peut etre long. De plus, au pire, on peut arriver a des organisations ou le nombre d'ouvertures peut etre le carre du nombre de fichier. L'idee date du temps des reseaux a 10MB, des machines sans disques, et de compilateurs sans en-tetes precompiles.
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
Matthieu Moy writes:
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
Note que ca fait un certain nombre de version que le preprocesseur est integre au compilateur dans gcc.
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
Sauf que l'analyse lexicographique, il faut la refaire pendant la
compilation en elle même, du moins avec g++ qui utilise des processus
séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
Note que ca fait un certain nombre de version que le preprocesseur est
integre au compilateur dans gcc.
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
Sauf que l'analyse lexicographique, il faut la refaire pendant la compilation en elle même, du moins avec g++ qui utilise des processus séparés pour le préprocesseur (cpp) et la compilation (cc1plus).
Note que ca fait un certain nombre de version que le preprocesseur est integre au compilateur dans gcc.
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
Matthieu Moy
Jean-Marc Bourguet writes:
Note que ca fait un certain nombre de version que le preprocesseur est integre au compilateur dans gcc.
A+
-- Matthieu
Jean-Marc Bourguet <jm@bourguet.org> writes:
Note que ca fait un certain nombre de version que le preprocesseur est
integre au compilateur dans gcc.
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...
"Avoid using the obsolete external include guards advocated in older books."
"External include guards are tedious, are obsolete on today's compilers, and are fragile with tight coupling because the caller and header must agree on the guard name."
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 873buq1yxm.fsf@news.bourguet.org,
"Michel Michaud" <mm@gdzid.com> 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...
"Avoid using the obsolete external include guards advocated in older
books."
"External include guards are tedious, are obsolete on today's
compilers, and are fragile with tight coupling because the caller and
header must agree on the guard name."
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:
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...
"Avoid using the obsolete external include guards advocated in older books."
"External include guards are tedious, are obsolete on today's compilers, and are fragile with tight coupling because the caller and header must agree on the guard name."
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
Marc Boyer
James Kanze wrote:
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H #include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
James Kanze wrote:
Ç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. Si
certains compilateurs, comme g++, détectent l'idiome des gardes de
l'inclusion, et évite de rouvrir le fichier un deuxième fois si
ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne
valait mieux pas faire un répertoire
/small-include
ou chaque fichier toto.h serait simplement
#ifndef TOTO_H
#define TOTO_H
#include "real-include/toto.h"
#endif
Ca se génére automatiquement, et ça permet de garder un code propre.
Et on peut quand même espérer que lire des fichiers de 4 lignes,
ce soit pas trop pénalisant pour cpp, non ?
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H #include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Jean-Marc Bourguet
Marc Boyer writes:
James Kanze wrote:
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas ici.
#include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier (je n'ai jamais fait d'experience avec les gardes externes). Pour ce facteur, tout depend ou tu places le small-include.
Note qu'avec au moins un systeme de gestion de source (clearcase), acceder aux sources est en pratique encore plus couteux que de lire un fichier via NFS. (Et pour clearcase, la configuration peut faire gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu un expert qui a change quelques paramatres, ca a change pas mal notre perception de l'efficacite du systeme).
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
James Kanze wrote:
Ç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. Si
certains compilateurs, comme g++, détectent l'idiome des gardes de
l'inclusion, et évite de rouvrir le fichier un deuxième fois si
ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne
valait mieux pas faire un répertoire
/small-include
ou chaque fichier toto.h serait simplement
#ifndef TOTO_H
#define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas
ici.
#include "real-include/toto.h"
#endif
Ca se génére automatiquement, et ça permet de garder un code propre.
Et on peut quand même espérer que lire des fichiers de 4 lignes,
ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un
fichier sur le reseau plus que la taille du fichier (je n'ai jamais
fait d'experience avec les gardes externes). Pour ce facteur, tout
depend ou tu places le small-include.
Note qu'avec au moins un systeme de gestion de source (clearcase),
acceder aux sources est en pratique encore plus couteux que de lire un
fichier via NFS. (Et pour clearcase, la configuration peut faire
gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu
un expert qui a change quelques paramatres, ca a change pas mal notre
perception de l'efficacite du systeme).
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
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas ici.
#include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier (je n'ai jamais fait d'experience avec les gardes externes). Pour ce facteur, tout depend ou tu places le small-include.
Note qu'avec au moins un systeme de gestion de source (clearcase), acceder aux sources est en pratique encore plus couteux que de lire un fichier via NFS. (Et pour clearcase, la configuration peut faire gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu un expert qui a change quelques paramatres, ca a change pas mal notre perception de l'efficacite du systeme).
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
Marc Boyer
In article , Jean-Marc Bourguet wrote:
Marc Boyer writes:
James Kanze wrote:
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas ici.
Ben, vu qu'on fait le test #ifndef sur la valeur du #define, qu'on fasse le #define ici ou ailleurs. De toute manière, l'idée était bien sur de récupérer la garde dans le vrai fichier.
#include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier (je n'ai jamais fait d'experience avec les gardes externes). Pour ce facteur, tout depend ou tu places le small-include.
Oui, optimiser sans savoir ou est le goulot d'étranglement, c'est toujours hazardeux. Après, faut jouer avec strace, truss, tout ça. Mais avant de demander aux développeurs d'aller modifier à la main tous les sources, je serais quand même tenté de commencer par ma version.
Note qu'avec au moins un systeme de gestion de source (clearcase), acceder aux sources est en pratique encore plus couteux que de lire un fichier via NFS. (Et pour clearcase, la configuration peut faire gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu un expert qui a change quelques paramatres, ca a change pas mal notre perception de l'efficacite du systeme).
Là aussi, savoir ou ça coince avant de faire quoi que ce soit. Mais si on peut exclure des sources du système de gestion, on peut utiliser ma technique.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
In article <pxbpsxtthf4.fsf@news.bourguet.org>, Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
James Kanze wrote:
Ç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. Si
certains compilateurs, comme g++, détectent l'idiome des gardes de
l'inclusion, et évite de rouvrir le fichier un deuxième fois si
ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne
valait mieux pas faire un répertoire
/small-include
ou chaque fichier toto.h serait simplement
#ifndef TOTO_H
#define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas
ici.
Ben, vu qu'on fait le test #ifndef sur la valeur du #define,
qu'on fasse le #define ici ou ailleurs.
De toute manière, l'idée était bien sur de récupérer la garde
dans le vrai fichier.
#include "real-include/toto.h"
#endif
Ca se génére automatiquement, et ça permet de garder un code propre.
Et on peut quand même espérer que lire des fichiers de 4 lignes,
ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un
fichier sur le reseau plus que la taille du fichier (je n'ai jamais
fait d'experience avec les gardes externes). Pour ce facteur, tout
depend ou tu places le small-include.
Oui, optimiser sans savoir ou est le goulot d'étranglement,
c'est toujours hazardeux. Après, faut jouer avec strace, truss,
tout ça.
Mais avant de demander aux développeurs d'aller modifier à la
main tous les sources, je serais quand même tenté de commencer
par ma version.
Note qu'avec au moins un systeme de gestion de source (clearcase),
acceder aux sources est en pratique encore plus couteux que de lire un
fichier via NFS. (Et pour clearcase, la configuration peut faire
gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu
un expert qui a change quelques paramatres, ca a change pas mal notre
perception de l'efficacite du systeme).
Là aussi, savoir ou ça coince avant de faire quoi que ce soit.
Mais si on peut exclure des sources du système de gestion, on
peut utiliser ma technique.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Ç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. Si certains compilateurs, comme g++, détectent l'idiome des gardes de l'inclusion, et évite de rouvrir le fichier un deuxième fois si ce n'est pas nécessaire, ce n'est pas le cas de tous.
Dans ce genre de cas, je me suis souvent demandé s'il ne valait mieux pas faire un répertoire /small-include ou chaque fichier toto.h serait simplement #ifndef TOTO_H #define TOTO_H
J'utiliserais la garde du "vrai" toto.h. Donc je la definirais pas ici.
Ben, vu qu'on fait le test #ifndef sur la valeur du #define, qu'on fasse le #define ici ou ailleurs. De toute manière, l'idée était bien sur de récupérer la garde dans le vrai fichier.
#include "real-include/toto.h" #endif
Ca se génére automatiquement, et ça permet de garder un code propre. Et on peut quand même espérer que lire des fichiers de 4 lignes, ce soit pas trop pénalisant pour cpp, non ?
Je me demande si un facteur important n'etait pas l'ouverture d'un fichier sur le reseau plus que la taille du fichier (je n'ai jamais fait d'experience avec les gardes externes). Pour ce facteur, tout depend ou tu places le small-include.
Oui, optimiser sans savoir ou est le goulot d'étranglement, c'est toujours hazardeux. Après, faut jouer avec strace, truss, tout ça. Mais avant de demander aux développeurs d'aller modifier à la main tous les sources, je serais quand même tenté de commencer par ma version.
Note qu'avec au moins un systeme de gestion de source (clearcase), acceder aux sources est en pratique encore plus couteux que de lire un fichier via NFS. (Et pour clearcase, la configuration peut faire gagner beaucoup, je ne me souviens pas de chiffres, mais quand on a eu un expert qui a change quelques paramatres, ca a change pas mal notre perception de l'efficacite du systeme).
Là aussi, savoir ou ça coince avant de faire quoi que ce soit. Mais si on peut exclure des sources du système de gestion, on peut utiliser ma technique.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
