j'ai du mal avec un code C++, et je soupsonne un bug de GCC 3.3.x.
Je n'arrive néanmoins pas à le trouver dans la base de donnée
des bugs (mais j'utilise peut-être pas les bons mots clef).
Voilà, est-ce que le nombre de caractères significatifs pour
une classe pourrait-être tout petit en GCC 3.3 ?
J'ai deux classes template: StateSpace et StateSpaceNode,
et je me demande s'il ne les confond pas parfois.
Si vous en avez connaissance, merci de me le dire avant que je
tente le passage à GCC 3.4 (je suis pas partant, ma tentative
de passage 3.2 à 3.3 a conduit à une réinstallation complète
de la machine: oui, je suis nul en administration Linux).
Merci d'avance,
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.
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
Tu travailles pour ILOG gartuitement ? ;-) Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je
demanderais une sérieuse augmentation... :)
Plus ou moins que si on te demandais de faire du Lisp ?
Entre lisp et perl, il n'y a pas photo. lisp gagne a tous les coups.
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
Loïc Joly <loic.actarus.joly@wanadoo.fr> writes:
Arnaud Meurgues wrote:
Gabriel Dos Reis wrote:
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire
| faire du perl.
Tu travailles pour ILOG gartuitement ? ;-)
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je
demanderais une sérieuse augmentation... :)
Plus ou moins que si on te demandais de faire du Lisp ?
Entre lisp et perl, il n'y a pas photo. lisp gagne a tous
les coups.
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
| m4, je ne connais pas. Mais il faudrait me payer cher pour me faire | faire du perl.
Tu travailles pour ILOG gartuitement ? ;-) Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je
demanderais une sérieuse augmentation... :)
Plus ou moins que si on te demandais de faire du Lisp ?
Entre lisp et perl, il n'y a pas photo. lisp gagne a tous les coups.
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
(La prochaine version de cette proposition n'utilisera probablement pas « scope », puisque cela crée certaines confusions. Moi, j'aime bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais cela semble politiquement pour certains).
Étrange. Je trouve que « scope » est très bien. De quelles confusions parles-tu ? Avec la définition de scope du C++ ?
PS: Cela fait maintenant +/- une semaine que j'ai des difficultés avec le site du WG21. En une heure, je n'arrive même pas à rappatrier complètement la page référençant les papiers de 2004. D'autres ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai essayé open-std et dkuug) ?
--drkm
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
(La prochaine version de cette proposition n'utilisera probablement
pas « scope », puisque cela crée certaines confusions. Moi, j'aime
bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais
cela semble politiquement pour certains).
Étrange. Je trouve que « scope » est très bien. De quelles
confusions parles-tu ? Avec la définition de scope du C++ ?
PS: Cela fait maintenant +/- une semaine que j'ai des difficultés
avec le site du WG21. En une heure, je n'arrive même pas à rappatrier
complètement la page référençant les papiers de 2004. D'autres
ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai
essayé open-std et dkuug) ?
(La prochaine version de cette proposition n'utilisera probablement pas « scope », puisque cela crée certaines confusions. Moi, j'aime bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais cela semble politiquement pour certains).
Étrange. Je trouve que « scope » est très bien. De quelles confusions parles-tu ? Avec la définition de scope du C++ ?
PS: Cela fait maintenant +/- une semaine que j'ai des difficultés avec le site du WG21. En une heure, je n'arrive même pas à rappatrier complètement la page référençant les papiers de 2004. D'autres ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai essayé open-std et dkuug) ?
--drkm
Gabriel Dos Reis
drkm writes:
| Gabriel Dos Reis writes: | | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1614.pdf | | > (La prochaine version de cette proposition n'utilisera probablement | > pas « scope », puisque cela crée certaines confusions. Moi, j'aime | > bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais | > cela semble politiquement pour certains). | | Étrange. Je trouve que « scope » est très bien.
Alors c'est que « scope » crée vraiment de la confusion :-)
| De quelles | confusions parles-tu ? Avec la définition de scope du C++ ?
Regarde la contre-proposotion de Tom Plum dans les pre- et/ou post-mainling de Redmond.
| PS: Cela fait maintenant +/- une semaine que j'ai des difficultés | avec le site du WG21. En une heure, je n'arrive même pas à rappatrier | complètement la page référençant les papiers de 2004. D'autres | ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai | essayé open-std et dkuug) ?
J'ai entendu dire que certains avaient des problèmes à rapatrier ces papiers -- car l'hébergeant actuel aurait mis certaines limites relativement basses aux débits. D'après ce que j'ai compris cela devrait être temporaire...
-- Gaby
drkm <usenet.fclcxx@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
|
| > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1614.pdf
|
| > (La prochaine version de cette proposition n'utilisera probablement
| > pas « scope », puisque cela crée certaines confusions. Moi, j'aime
| > bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais
| > cela semble politiquement pour certains).
|
| Étrange. Je trouve que « scope » est très bien.
Alors c'est que « scope » crée vraiment de la confusion :-)
| De quelles
| confusions parles-tu ? Avec la définition de scope du C++ ?
Regarde la contre-proposotion de Tom Plum dans les pre- et/ou
post-mainling de Redmond.
| PS: Cela fait maintenant +/- une semaine que j'ai des difficultés
| avec le site du WG21. En une heure, je n'arrive même pas à rappatrier
| complètement la page référençant les papiers de 2004. D'autres
| ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai
| essayé open-std et dkuug) ?
J'ai entendu dire que certains avaient des problèmes à rapatrier ces
papiers -- car l'hébergeant actuel aurait mis certaines limites
relativement basses aux débits. D'après ce que j'ai compris cela
devrait être temporaire...
| Gabriel Dos Reis writes: | | > http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1614.pdf | | > (La prochaine version de cette proposition n'utilisera probablement | > pas « scope », puisque cela crée certaines confusions. Moi, j'aime | > bien « #nospam » -- comme on peut le voir dans la liste de EWG -- mais | > cela semble politiquement pour certains). | | Étrange. Je trouve que « scope » est très bien.
Alors c'est que « scope » crée vraiment de la confusion :-)
| De quelles | confusions parles-tu ? Avec la définition de scope du C++ ?
Regarde la contre-proposotion de Tom Plum dans les pre- et/ou post-mainling de Redmond.
| PS: Cela fait maintenant +/- une semaine que j'ai des difficultés | avec le site du WG21. En une heure, je n'arrive même pas à rappatrier | complètement la page référençant les papiers de 2004. D'autres | ont-ils le même problème ? Y a-t-il un mirroir utilisable (j'ai | essayé open-std et dkuug) ?
J'ai entendu dire que certains avaient des problèmes à rapatrier ces papiers -- car l'hébergeant actuel aurait mis certaines limites relativement basses aux débits. D'après ce que j'ai compris cela devrait être temporaire...
-- Gaby
Marc Boyer
In article <cnvp0h$51$, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnvjdi$hdl$, Laurent Deniau wrote:
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier.
Hu ? Quand un fichier fait un #include d'un autre, ils ne forment qu'une TU il me semble, non ?
Oui. Mais tu veux que tes blocs s'arretent au premier #include ou qu'un #include dans un bloc ne soit pas considere? C'est pour ca que je prefere parler de TU, c'est plus simple que de parler de fichier.
Je n'ai pas de proposition formelle: je sens des limitations à cpp et j'entrevois des pistes de solutions. Certaines sont peut-être des impasses.
Des portees en cpp? Definies par quoi?
Et bien, des identifiants de porté ;-) #openbloc #closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass #define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main. J'ai aussi le même genre de chose dans la BPL: #include "CleanVectorMacros.h"
Si je devais faire un parallèle, c'est un peut comme l'appel systématique des destructeurs des variables locales en C++: tu pourrais le faire à la main, mais le compilateur est moins étourdit que le programmeur.
Ce que je reproche à cpp n'est pas tellement sa complexité que le manque de protection face à l'étourderie, ou, dit autrement, l'absence de support pour un partitionnement de la complexité du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de trucs (peut-etre meme une collaboration avec le systeme de type du langage).
Comme je disais, peut-être que certaines directtions sont trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre que le mécanisme de protection contre l'inclusion multiple était couteux parce que cpp doit re-parser chaque fois le fichier pour constater que le #endif est bien à la fin du fichier. Avec un #includeonce (ou #import ou autre), on résoud ce problème.
Alors oui, le danger est de faire un truc trop lourd. Mais justement, c'est peut-être de la communauté C++ que pourrais sortir une solution, puisque les templates font déjà pas mal de boulot, on serait moins tenter de mettre ces fonctionnalités dans le preprocesseur.
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 <cnvp0h$51$1@sunnews.cern.ch>, Laurent Deniau wrote:
Marc Boyer wrote:
In article <cnvjdi$hdl$1@sunnews.cern.ch>, Laurent Deniau wrote:
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier.
Hu ?
Quand un fichier fait un #include d'un autre, ils ne forment
qu'une TU il me semble, non ?
Oui. Mais tu veux que tes blocs s'arretent au premier #include ou qu'un
#include dans un bloc ne soit pas considere? C'est pour ca que je
prefere parler de TU, c'est plus simple que de parler de fichier.
Je n'ai pas de proposition formelle: je sens des limitations
à cpp et j'entrevois des pistes de solutions. Certaines sont
peut-être des impasses.
Des portees en cpp? Definies par quoi?
Et bien, des identifiants de porté ;-)
#openbloc
#closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une
classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass
#define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main.
J'ai aussi le même genre de chose dans la BPL:
#include "CleanVectorMacros.h"
Si je devais faire un parallèle, c'est un peut comme l'appel
systématique des destructeurs des variables locales en C++:
tu pourrais le faire à la main, mais le compilateur est moins
étourdit que le programmeur.
Ce que je reproche à cpp n'est pas tellement sa complexité
que le manque de protection face à l'étourderie, ou, dit autrement,
l'absence de support pour un partitionnement de la complexité
du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de
trucs (peut-etre meme une collaboration avec le systeme de type du
langage).
Comme je disais, peut-être que certaines directtions sont
trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal
de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre
que le mécanisme de protection contre l'inclusion multiple était
couteux parce que cpp doit re-parser chaque fois le fichier
pour constater que le #endif est bien à la fin du fichier.
Avec un #includeonce (ou #import ou autre), on résoud ce
problème.
Alors oui, le danger est de faire un truc trop lourd. Mais
justement, c'est peut-être de la communauté C++ que pourrais
sortir une solution, puisque les templates font déjà pas mal
de boulot, on serait moins tenter de mettre ces fonctionnalités
dans le preprocesseur.
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.
Local au fichier par exemple. Ou introduire des portées en cpp.
TU = translation unit, ce que tu appelles le fichier.
Hu ? Quand un fichier fait un #include d'un autre, ils ne forment qu'une TU il me semble, non ?
Oui. Mais tu veux que tes blocs s'arretent au premier #include ou qu'un #include dans un bloc ne soit pas considere? C'est pour ca que je prefere parler de TU, c'est plus simple que de parler de fichier.
Je n'ai pas de proposition formelle: je sens des limitations à cpp et j'entrevois des pistes de solutions. Certaines sont peut-être des impasses.
Des portees en cpp? Definies par quoi?
Et bien, des identifiants de porté ;-) #openbloc #closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass #define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main. J'ai aussi le même genre de chose dans la BPL: #include "CleanVectorMacros.h"
Si je devais faire un parallèle, c'est un peut comme l'appel systématique des destructeurs des variables locales en C++: tu pourrais le faire à la main, mais le compilateur est moins étourdit que le programmeur.
Ce que je reproche à cpp n'est pas tellement sa complexité que le manque de protection face à l'étourderie, ou, dit autrement, l'absence de support pour un partitionnement de la complexité du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de trucs (peut-etre meme une collaboration avec le systeme de type du langage).
Comme je disais, peut-être que certaines directtions sont trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre que le mécanisme de protection contre l'inclusion multiple était couteux parce que cpp doit re-parser chaque fois le fichier pour constater que le #endif est bien à la fin du fichier. Avec un #includeonce (ou #import ou autre), on résoud ce problème.
Alors oui, le danger est de faire un truc trop lourd. Mais justement, c'est peut-être de la communauté C++ que pourrais sortir une solution, puisque les templates font déjà pas mal de boulot, on serait moins tenter de mettre ces fonctionnalités dans le preprocesseur.
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.
Arnaud Meurgues
Loïc Joly wrote:
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je demanderais une sérieuse augmentation... :) Plus ou moins que si on te demandais de faire du Lisp ?
Plus.
-- Arnaud (Supprimez les geneurs pour me répondre)
Loïc Joly wrote:
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon,
je demanderais une sérieuse augmentation... :)
Plus ou moins que si on te demandais de faire du Lisp ?
Plus.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Non. Mais on ne me demande pas, Dieu merci, de faire du perl. Sinon, je demanderais une sérieuse augmentation... :) Plus ou moins que si on te demandais de faire du Lisp ?
Plus.
-- Arnaud (Supprimez les geneurs pour me répondre)
Laurent Deniau
Marc Boyer wrote:
In article <cnvp0h$51$, Laurent Deniau wrote:
Et bien, des identifiants de porté ;-) #openbloc #closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass #define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main.
#openscope #closescope
aussi. Les defines, c'est autre chose, ils sont la pour caracteriser l'interface.
J'ai aussi le même genre de chose dans la BPL: #include "CleanVectorMacros.h"
Ca ce n'est pas la meme chose. OpenInterface et CloseInterface change en fonction du contexte, notament OpenInterface #undef OpenInterface et #define CloseInterface pour verifier la parite. Toi tu charges un fichier pour faire du nettoyage.
Si je devais faire un parallèle, c'est un peut comme l'appel systématique des destructeurs des variables locales en C++: tu pourrais le faire à la main, mais le compilateur est moins étourdit que le programmeur.
C'est sur.
Ce que je reproche à cpp n'est pas tellement sa complexité que le manque de protection face à l'étourderie, ou, dit autrement, l'absence de support pour un partitionnement de la complexité du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de trucs (peut-etre meme une collaboration avec le systeme de type du langage).
Comme je disais, peut-être que certaines directtions sont trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre que le mécanisme de protection contre l'inclusion multiple était couteux parce que cpp doit re-parser chaque fois le fichier pour constater que le #endif est bien à la fin du fichier. Avec un #includeonce (ou #import ou autre), on résoud ce problème.
Et on en creer d'autre. #import (present dans Objective-C) est tres controverse. Si ces gens voient un probleme de performance, ils peuvent rajouter des balises autour des includes, comme le preconise Lakos.
Perso je prefere hierarchiser mes includes. Si un header a deja ete lu, le relire n'est pas un probleme parce qu'il est petit. Par contre la branche d'includes qui est derriere n'est plus vue. J'ai pas eu de probleme de performance jusqu'a maintenant.
Alors oui, le danger est de faire un truc trop lourd. Mais justement, c'est peut-être de la communauté C++ que pourrais sortir une solution, puisque les templates font déjà pas mal de boulot, on serait moins tenter de mettre ces fonctionnalités dans le preprocesseur.
a+, ld.
Marc Boyer wrote:
In article <cnvp0h$51$1@sunnews.cern.ch>, Laurent Deniau wrote:
Et bien, des identifiants de porté ;-)
#openbloc
#closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une
classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass
#define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main.
#openscope
#closescope
aussi. Les defines, c'est autre chose, ils sont la pour caracteriser
l'interface.
J'ai aussi le même genre de chose dans la BPL:
#include "CleanVectorMacros.h"
Ca ce n'est pas la meme chose. OpenInterface et CloseInterface change en
fonction du contexte, notament OpenInterface #undef OpenInterface et
#define CloseInterface pour verifier la parite. Toi tu charges un
fichier pour faire du nettoyage.
Si je devais faire un parallèle, c'est un peut comme l'appel
systématique des destructeurs des variables locales en C++:
tu pourrais le faire à la main, mais le compilateur est moins
étourdit que le programmeur.
C'est sur.
Ce que je reproche à cpp n'est pas tellement sa complexité
que le manque de protection face à l'étourderie, ou, dit autrement,
l'absence de support pour un partitionnement de la complexité
du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de
trucs (peut-etre meme une collaboration avec le systeme de type du
langage).
Comme je disais, peut-être que certaines directtions sont
trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal
de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre
que le mécanisme de protection contre l'inclusion multiple était
couteux parce que cpp doit re-parser chaque fois le fichier
pour constater que le #endif est bien à la fin du fichier.
Avec un #includeonce (ou #import ou autre), on résoud ce
problème.
Et on en creer d'autre. #import (present dans Objective-C) est tres
controverse. Si ces gens voient un probleme de performance, ils peuvent
rajouter des balises autour des includes, comme le preconise Lakos.
Perso je prefere hierarchiser mes includes. Si un header a deja ete lu,
le relire n'est pas un probleme parce qu'il est petit. Par contre la
branche d'includes qui est derriere n'est plus vue. J'ai pas eu de
probleme de performance jusqu'a maintenant.
Alors oui, le danger est de faire un truc trop lourd. Mais
justement, c'est peut-être de la communauté C++ que pourrais
sortir une solution, puisque les templates font déjà pas mal
de boulot, on serait moins tenter de mettre ces fonctionnalités
dans le preprocesseur.
Et bien, des identifiants de porté ;-) #openbloc #closebloc
Arf. J'ai deja ca en OOC (les scopes). Le scope de l'interface d'une classe se definit comme:
#include <ooc/Object.h>
#include OpenInterface // peut inclure des defines
#define CLASS MyClass #define SUPER Object
#include CloseInterface // inclus du nettoyage, CLASS et SUPER inclus
Ca ressemble presque non?
Oui, mais tu te le fais à la main.
#openscope #closescope
aussi. Les defines, c'est autre chose, ils sont la pour caracteriser l'interface.
J'ai aussi le même genre de chose dans la BPL: #include "CleanVectorMacros.h"
Ca ce n'est pas la meme chose. OpenInterface et CloseInterface change en fonction du contexte, notament OpenInterface #undef OpenInterface et #define CloseInterface pour verifier la parite. Toi tu charges un fichier pour faire du nettoyage.
Si je devais faire un parallèle, c'est un peut comme l'appel systématique des destructeurs des variables locales en C++: tu pourrais le faire à la main, mais le compilateur est moins étourdit que le programmeur.
C'est sur.
Ce que je reproche à cpp n'est pas tellement sa complexité que le manque de protection face à l'étourderie, ou, dit autrement, l'absence de support pour un partitionnement de la complexité du problème.
Si tu parts dans cette direction, tu vas vouloir lui ajouter plein de trucs (peut-etre meme une collaboration avec le systeme de type du langage).
Comme je disais, peut-être que certaines directtions sont trop lourdes.
Je prefere qu'il reste simple et *rapide*. Il a deja pas mal de boulot a faire le pauvre...
Tiens, parlons du pb de perf: j'ai entendu des gens se plaindre que le mécanisme de protection contre l'inclusion multiple était couteux parce que cpp doit re-parser chaque fois le fichier pour constater que le #endif est bien à la fin du fichier. Avec un #includeonce (ou #import ou autre), on résoud ce problème.
Et on en creer d'autre. #import (present dans Objective-C) est tres controverse. Si ces gens voient un probleme de performance, ils peuvent rajouter des balises autour des includes, comme le preconise Lakos.
Perso je prefere hierarchiser mes includes. Si un header a deja ete lu, le relire n'est pas un probleme parce qu'il est petit. Par contre la branche d'includes qui est derriere n'est plus vue. J'ai pas eu de probleme de performance jusqu'a maintenant.
Alors oui, le danger est de faire un truc trop lourd. Mais justement, c'est peut-être de la communauté C++ que pourrais sortir une solution, puisque les templates font déjà pas mal de boulot, on serait moins tenter de mettre ces fonctionnalités dans le preprocesseur.
