dans le cadre d'un projet en C assez important, où on défini plusieurs
fichier.h définissant des types, incluant des bibliothèques etc... je
cherche des infos sur comment organiser tout ça au mieux pour ne pas que ça
devienne le souk au bout d'un certain temps avec des include par ici,
d'autres définitions par là... des trucs qui se croisent dans tous les sens
etc...
faut-il par exemple y aller a gros coup de
#ifndef CONSTANTE
#define CONSTANTE
Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux. c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs heures.
Mais un des objectifs de la compilation séparée, c'est de ne pas avoir à "tout" compiler d'un coup il me semble. Et ça me semble tellement source de bug potentiel ce truc.
Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et parser un fichier, c'est pas la même chose.
Toute règle peut être violée, si on sait bien pourquoi. Mais on perd tellement en indépendance entre modules que j'aurais préférence à modifier le code du header lui même: --- foo.h --- #ifndef FOO_H #define FOO_H #include "foo_implem.h" #endif plutôt que d'aller changer le code client (d'autant qu'avec une moulinette type awk/perl, c'est 2mn à faire).
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <3F252622.4010703@tb.fr>, AG wrote:
Avec le même genre d'argument, on enlève les commentaires (ça fatigue
le préprocesseur) et on choisit des noms de variable de moins de 3 lettres
pour ne pas surcharger la table des symboles.
Soyons sérieux.
c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs
heures.
Mais un des objectifs de la compilation séparée, c'est de ne
pas avoir à "tout" compiler d'un coup il me semble.
Et ça me semble tellement source de bug potentiel ce truc.
Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et
parser un fichier, c'est pas la même chose.
Toute règle peut être violée, si on sait bien pourquoi.
Mais on perd tellement en indépendance entre modules que
j'aurais préférence à modifier le code du header lui même:
--- foo.h ---
#ifndef FOO_H
#define FOO_H
#include "foo_implem.h"
#endif
plutôt que d'aller changer le code client (d'autant qu'avec
une moulinette type awk/perl, c'est 2mn à faire).
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux. c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs heures.
Mais un des objectifs de la compilation séparée, c'est de ne pas avoir à "tout" compiler d'un coup il me semble. Et ça me semble tellement source de bug potentiel ce truc.
Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et parser un fichier, c'est pas la même chose.
Toute règle peut être violée, si on sait bien pourquoi. Mais on perd tellement en indépendance entre modules que j'aurais préférence à modifier le code du header lui même: --- foo.h --- #ifndef FOO_H #define FOO_H #include "foo_implem.h" #endif plutôt que d'aller changer le code client (d'autant qu'avec une moulinette type awk/perl, c'est 2mn à faire).
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
AG
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux. c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs heures. Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et parser un fichier, c'est pas la même chose.
Huuh...
Avec le même genre d'argument, on enlève les commentaires (ça fatigue
le préprocesseur) et on choisit des noms de variable de moins de 3 lettres
pour ne pas surcharger la table des symboles.
Soyons sérieux.
c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs
heures.
Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et
parser un fichier, c'est pas la même chose.
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux. c'est pas parce que ça l'use, c'est parce que ça prends du temps. J'ai
travaillé sur un projet sur lequel compiler le tout prenais plusieurs heures. Ce genre d'"optimisation" n'était pas du luxe. Parser un commentaire et parser un fichier, c'est pas la même chose.
Antoine Leca
Marc Boyer écrivit:
Yves ROMAN wrote:
In article , Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
(J'adore ce genre de commentaire, en particulier quand je tombe dessus quelques années plus tard sur DejaNews/Deja/Google/SonRemplaçant ;-))
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève les protections de sur-inclusions (je ne sais même pas si glibc compile si tu enlèves les protections, c'est tellement le foutoir, mais bon), lance une compilation "pour te faire la main", change un caractère quelque part dans un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances croisées; avec de multiples inclusions de la même chose, cela explose pour les références aux objets "centraux" (genre FILE).
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Antoine
Marc Boyer écrivit:
Yves ROMAN wrote:
In article <3F2152FC.C106E504@unilog.fr>, Yves ROMAN wrote:
Et si tu veux gerer des inclusions de fichiers dans des fichiers
inclus (il y a du pour et du contre...)
tu peux en profiter pour eviter d'inclure un fichier s'il la deja
ete, pour simplifier la tache au compilateur.
Quel intérêt
Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même
fichier pour rien
Huuh...
Avec le même genre d'argument, on enlève les commentaires (ça
fatigue le préprocesseur) et on choisit des noms de variable de moins de 3
lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire
qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines
n'ont pas toutes « forcément » 64 Mio.
(J'adore ce genre de commentaire, en particulier quand je tombe dessus
quelques années plus tard sur DejaNews/Deja/Google/SonRemplaçant ;-))
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève
les
protections de sur-inclusions (je ne sais même pas si glibc compile si tu
enlèves les protections, c'est tellement le foutoir, mais bon), lance une
compilation "pour te faire la main", change un caractère quelque part dans
un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances
croisées; avec de multiples inclusions de la même chose, cela explose pour
les références aux objets "centraux" (genre FILE).
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom
de la constante utilisée a l'intérieur du fichier. Cela nécessite
une nomenclature rigide.
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Et si tu veux gerer des inclusions de fichiers dans des fichiers inclus (il y a du pour et du contre...) tu peux en profiter pour eviter d'inclure un fichier s'il la deja ete, pour simplifier la tache au compilateur.
Quel intérêt Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
(J'adore ce genre de commentaire, en particulier quand je tombe dessus quelques années plus tard sur DejaNews/Deja/Google/SonRemplaçant ;-))
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève les protections de sur-inclusions (je ne sais même pas si glibc compile si tu enlèves les protections, c'est tellement le foutoir, mais bon), lance une compilation "pour te faire la main", change un caractère quelque part dans un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances croisées; avec de multiples inclusions de la même chose, cela explose pour les références aux objets "centraux" (genre FILE).
Effectivement, car il faut savoir, a l'extérieur du fichier, le nom de la constante utilisée a l'intérieur du fichier. Cela nécessite une nomenclature rigide.
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Antoine
Marc Boyer
Antoine Leca wrote:
Marc Boyer écrivit:
Yves ROMAN wrote:
In article , Yves ROMAN wrote:
Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ du projet ? Ca ressemble plus à une rustine qu'autre chose.
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève les protections de sur-inclusions (je ne sais même pas si glibc compile si tu enlèves les protections, c'est tellement le foutoir, mais bon), lance une compilation "pour te faire la main", change un caractère quelque part dans un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances croisées; avec de multiples inclusions de la même chose, cela explose pour les références aux objets "centraux" (genre FILE).
Je confesse mon manque de culture générale sur le sujet, mais ça me semble quand même une mauvaise solution à un vrai problème. Il me semblerait quand même plus logique dans ce cadre de faire gérer ce genre d'optimisation par un outil extérieur automatiquement (awk/sed/perl). Non ?
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Heuh... La chasse au Troll est pas interdite en Juillet/Aout ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Antoine Leca wrote:
Marc Boyer écrivit:
Yves ROMAN wrote:
In article <3F2152FC.C106E504@unilog.fr>, Yves ROMAN wrote:
Que ça compile plus vite ?
Oui : pour éviter au précompilateur de parser 3000 fois un même
fichier pour rien
Huuh...
Avec le même genre d'argument, on enlève les commentaires (ça
fatigue le préprocesseur) et on choisit des noms de variable de moins de 3
lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire
qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines
n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ
du projet ? Ca ressemble plus à une rustine qu'autre chose.
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève
les
protections de sur-inclusions (je ne sais même pas si glibc compile si tu
enlèves les protections, c'est tellement le foutoir, mais bon), lance une
compilation "pour te faire la main", change un caractère quelque part dans
un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances
croisées; avec de multiples inclusions de la même chose, cela explose pour
les références aux objets "centraux" (genre FILE).
Je confesse mon manque de culture générale sur le sujet,
mais ça me semble quand même une mauvaise solution à un
vrai problème.
Il me semblerait quand même plus logique dans ce cadre
de faire gérer ce genre d'optimisation par un outil extérieur
automatiquement (awk/sed/perl).
Non ?
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Heuh...
La chasse au Troll est pas interdite en Juillet/Aout ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Oui : pour éviter au précompilateur de parser 3000 fois un même fichier pour rien
Huuh... Avec le même genre d'argument, on enlève les commentaires (ça fatigue le préprocesseur) et on choisit des noms de variable de moins de 3 lettres pour ne pas surcharger la table des symboles.
Soyons sérieux.
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ du projet ? Ca ressemble plus à une rustine qu'autre chose.
Si tu veux faire un essai, prend « au hasard » glibc ou kernel, et enlève les protections de sur-inclusions (je ne sais même pas si glibc compile si tu enlèves les protections, c'est tellement le foutoir, mais bon), lance une compilation "pour te faire la main", change un caractère quelque part dans un commentaire d'un fichier de config, et "make"...
Autre point, certains compilateurs génèrent des informations de dépendances croisées; avec de multiples inclusions de la même chose, cela explose pour les références aux objets "centraux" (genre FILE).
Je confesse mon manque de culture générale sur le sujet, mais ça me semble quand même une mauvaise solution à un vrai problème. Il me semblerait quand même plus logique dans ce cadre de faire gérer ce genre d'optimisation par un outil extérieur automatiquement (awk/sed/perl). Non ?
Et on brise plein de beaux principes d'encapsulation.
Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
Heuh... La chasse au Troll est pas interdite en Juillet/Aout ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Marc Boyer writes:
| >> Et on brise plein de beaux principes d'encapsulation. | > | > Les beaux principes d'encapsulation n'ont pas leur place ici (fclc). | | Heuh... | La chasse au Troll est pas interdite en Juillet/Aout ?
Yep, directive européenne.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| >> Et on brise plein de beaux principes d'encapsulation.
| >
| > Les beaux principes d'encapsulation n'ont pas leur place ici (fclc).
|
| Heuh...
| La chasse au Troll est pas interdite en Juillet/Aout ?
| >> Et on brise plein de beaux principes d'encapsulation. | > | > Les beaux principes d'encapsulation n'ont pas leur place ici (fclc). | | Heuh... | La chasse au Troll est pas interdite en Juillet/Aout ?
Yep, directive européenne.
-- Gaby
Marc Boyer
Antoine Leca wrote:
Marc Boyer écrivit:
Antoine Leca wrote:
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ du projet ? Ca ressemble plus à une rustine qu'autre chose.
Cette fois-ci, c'est à moi de te demander d'être sérieux. Si tu estimes qu'un projet C (lancé il y a disons 12 mois) nécessite obligatoirement en 2003 64 Mio, sinon il est « mal conçu », d'accord, c'est ton avis, je ne le partage pas. J'ai juste peur de ce que va demander son petit frère, le projet C++/Java/votre-OOL-préféré...
Non, je demandais si le fait qu'un code de 300 000 lignes soit incapable d'être compilé sans cette protection contre l'inclusion n'était pas révélateur de trop de dépendance. C'est juste une question, pas une critique.
Autrement dit, je pourrais souscrire à « mal conçu » si ce n'était que la seule méthode que l'on a trouvé aujourd'hui pour le génie logiciel, c'est la fuite en avant (relire maintenant _La Cathédrale et le Bazar_ en pensant à ce que je viens d'écrire, c'est très instructif je trouve...)
Disons que si c'est l'affirmation selon laquelle la seule méthode de géni log est la fuite en avant qui me fait tombre de haut.
mais ça me semble quand même une mauvaise solution à un vrai problème.
Ah ! nous y voilà.
Il me semblerait quand même plus logique dans ce cadre de faire gérer ce genre d'optimisation par un outil extérieur automatiquement (awk/sed/perl).
a) pas sûr que ce soit plus simple dans la pratique (et je ne suis sûrement pas le seul qui hésite à passer d'un code C que je contrôle à un script perl où j'entrave rien);
Faut évaluer la difficulté, en effet.
b) cauchemar à maintenir (tous ceux qui lisent l'autoconf tous les 4 matins, ce qui ne veut pas dire courament ;-), me comprendront)
Sauf que l'idée, c'est justement de pas maintenir le code modifié. Le code est modifié "à la volée" juste avant compilation.
c) nécessite d'abandonner make (qui ne comprend rien) et de passer à d'autres outils plus évolués pour cela, ce qui a l'inconvénient de faire fuir *beaucoup* de mainteneurs potentiels; position difficile dans une boîte si c'est toi le chef du développement (responsable technique ou directeur), intenable sur un projet OpenSource.
Non, pourquoi virer "make" ?
d) de quoi parle-t-on exactement ? il s'agit d'aller chercher le nom de la constante-qui-tue_H (avec un _ devant, sans, avec __, etc.) qui évitera la sur-inclusion, pour coller un #ifndef/#endif autour de l'#include, soit quasiment rien (on passe 1% de son temps à écrire les spécifications de base, et une portion infinitésimale de ce temps concerne les #include imbriqués); par contre, on trouve les joyeux puristes qui veulent _changer_ la norme de nommage des fameuses constantes... et ce sont ceux-là qui peuvent avoir besoin d'automatisation, et là oui, je les laisse jouer avec awk et perl... mais qu'on ne parle plus alors de conception, ce serait plutôt de la déception !
Je vois deux pistes en automatique: 1) soit oui coller le #ifndef/#endif autour de l'include à la volée, juste avant la compil 2) remplacer les #include "toto.h" par #include "toto_truc.h" en sachant que le fichier "toto_truc.h" fait 3 lignes #ifndef TOTO_H #include "toto.h" #endif
Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Antoine Leca wrote:
Marc Boyer écrivit:
Antoine Leca wrote:
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va
faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les
machines n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ
du projet ? Ca ressemble plus à une rustine qu'autre chose.
Cette fois-ci, c'est à moi de te demander d'être sérieux.
Si tu estimes qu'un projet C (lancé il y a disons 12 mois) nécessite
obligatoirement en 2003 64 Mio, sinon il est « mal conçu », d'accord,
c'est ton avis, je ne le partage pas. J'ai juste peur de ce que va
demander son petit frère, le projet C++/Java/votre-OOL-préféré...
Non, je demandais si le fait qu'un code de 300 000 lignes
soit incapable d'être compilé sans cette protection contre
l'inclusion n'était pas révélateur de trop de dépendance.
C'est juste une question, pas une critique.
Autrement dit, je pourrais souscrire à « mal conçu » si ce n'était
que la seule méthode que l'on a trouvé aujourd'hui pour le génie
logiciel, c'est la fuite en avant (relire maintenant _La Cathédrale
et le Bazar_ en pensant à ce que je viens d'écrire, c'est très
instructif je trouve...)
Disons que si c'est l'affirmation selon laquelle la seule
méthode de géni log est la fuite en avant qui me fait tombre
de haut.
mais ça me semble quand même une mauvaise solution à un
vrai problème.
Ah ! nous y voilà.
Il me semblerait quand même plus logique dans ce cadre
de faire gérer ce genre d'optimisation par un outil extérieur
automatiquement (awk/sed/perl).
a) pas sûr que ce soit plus simple dans la pratique (et je ne
suis sûrement pas le seul qui hésite à passer d'un code C
que je contrôle à un script perl où j'entrave rien);
Faut évaluer la difficulté, en effet.
b) cauchemar à maintenir (tous ceux qui lisent l'autoconf tous
les 4 matins, ce qui ne veut pas dire courament ;-), me
comprendront)
Sauf que l'idée, c'est justement de pas maintenir le
code modifié. Le code est modifié "à la volée" juste avant
compilation.
c) nécessite d'abandonner make (qui ne comprend rien) et
de passer à d'autres outils plus évolués pour cela, ce qui a
l'inconvénient de faire fuir *beaucoup* de mainteneurs potentiels;
position difficile dans une boîte si c'est toi le chef du
développement (responsable technique ou directeur), intenable
sur un projet OpenSource.
Non, pourquoi virer "make" ?
d) de quoi parle-t-on exactement ? il s'agit d'aller chercher le nom
de la constante-qui-tue_H (avec un _ devant, sans, avec __, etc.)
qui évitera la sur-inclusion, pour coller un #ifndef/#endif autour de
l'#include, soit quasiment rien (on passe 1% de son temps à
écrire les spécifications de base, et une portion infinitésimale de
ce temps concerne les #include imbriqués); par contre, on trouve
les joyeux puristes qui veulent _changer_ la norme de nommage
des fameuses constantes... et ce sont ceux-là qui peuvent avoir
besoin d'automatisation, et là oui, je les laisse jouer avec awk et
perl... mais qu'on ne parle plus alors de conception, ce serait
plutôt de la déception !
Je vois deux pistes en automatique:
1) soit oui coller le #ifndef/#endif autour de l'include
à la volée, juste avant la compil
2) remplacer les #include "toto.h" par #include "toto_truc.h"
en sachant que le fichier "toto_truc.h" fait 3 lignes
#ifndef TOTO_H
#include "toto.h"
#endif
Non ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
C'est pourtant l'argument (celui d'Yves, pas ta caricature) qui va faire qu'un projet de 300 kLOC va aboutir ou pas, sachant que les machines n'ont pas toutes « forcément » 64 Mio.
N'est-ce pas la preuve d'une mauvaise conception au départ du projet ? Ca ressemble plus à une rustine qu'autre chose.
Cette fois-ci, c'est à moi de te demander d'être sérieux. Si tu estimes qu'un projet C (lancé il y a disons 12 mois) nécessite obligatoirement en 2003 64 Mio, sinon il est « mal conçu », d'accord, c'est ton avis, je ne le partage pas. J'ai juste peur de ce que va demander son petit frère, le projet C++/Java/votre-OOL-préféré...
Non, je demandais si le fait qu'un code de 300 000 lignes soit incapable d'être compilé sans cette protection contre l'inclusion n'était pas révélateur de trop de dépendance. C'est juste une question, pas une critique.
Autrement dit, je pourrais souscrire à « mal conçu » si ce n'était que la seule méthode que l'on a trouvé aujourd'hui pour le génie logiciel, c'est la fuite en avant (relire maintenant _La Cathédrale et le Bazar_ en pensant à ce que je viens d'écrire, c'est très instructif je trouve...)
Disons que si c'est l'affirmation selon laquelle la seule méthode de géni log est la fuite en avant qui me fait tombre de haut.
mais ça me semble quand même une mauvaise solution à un vrai problème.
Ah ! nous y voilà.
Il me semblerait quand même plus logique dans ce cadre de faire gérer ce genre d'optimisation par un outil extérieur automatiquement (awk/sed/perl).
a) pas sûr que ce soit plus simple dans la pratique (et je ne suis sûrement pas le seul qui hésite à passer d'un code C que je contrôle à un script perl où j'entrave rien);
Faut évaluer la difficulté, en effet.
b) cauchemar à maintenir (tous ceux qui lisent l'autoconf tous les 4 matins, ce qui ne veut pas dire courament ;-), me comprendront)
Sauf que l'idée, c'est justement de pas maintenir le code modifié. Le code est modifié "à la volée" juste avant compilation.
c) nécessite d'abandonner make (qui ne comprend rien) et de passer à d'autres outils plus évolués pour cela, ce qui a l'inconvénient de faire fuir *beaucoup* de mainteneurs potentiels; position difficile dans une boîte si c'est toi le chef du développement (responsable technique ou directeur), intenable sur un projet OpenSource.
Non, pourquoi virer "make" ?
d) de quoi parle-t-on exactement ? il s'agit d'aller chercher le nom de la constante-qui-tue_H (avec un _ devant, sans, avec __, etc.) qui évitera la sur-inclusion, pour coller un #ifndef/#endif autour de l'#include, soit quasiment rien (on passe 1% de son temps à écrire les spécifications de base, et une portion infinitésimale de ce temps concerne les #include imbriqués); par contre, on trouve les joyeux puristes qui veulent _changer_ la norme de nommage des fameuses constantes... et ce sont ceux-là qui peuvent avoir besoin d'automatisation, et là oui, je les laisse jouer avec awk et perl... mais qu'on ne parle plus alors de conception, ce serait plutôt de la déception !
Je vois deux pistes en automatique: 1) soit oui coller le #ifndef/#endif autour de l'include à la volée, juste avant la compil 2) remplacer les #include "toto.h" par #include "toto_truc.h" en sachant que le fichier "toto_truc.h" fait 3 lignes #ifndef TOTO_H #include "toto.h" #endif
Non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
