J'ai un gros projet C++ où les include ont été fait n'importe comment. Je voudrais les corriger pour améliorer la lisibilité ainsi que les temps de calculs.
tu n'es pas assez précis sur le problème que tu rencontres (qu'est-ce qu'ils ont de moche ces includes ?)
et ce que tu cherches à faire, parce que corriger un include sans savoir la tête/le problème qu'il a ni ce que tu veux en faire: je sais pas faire.
de quel temps de calcul tu parles ? de l'exécutable final ou de la compilation ? (pour l'exécutable final, les includes n'y changeront rien)
J'avoue sourir en y pensant tellement ca parait simpliste de partir d'une idée comme ca. ;) je vais qd meme essayer si j'ai une machine qui ne sert a rien pdt qq temps (quelques semaines) :) (une compilation a 1h15 actuellement en mode debug...)
Je te tiens au courant comment ca se passera. Ca se rajoute du coup dans ma file de projet ;)
bienvenu dans le monde de l'entreprise et des gros projets ...
J'ai souvent ete confronté a ce genre de pb. Il n'y a pas de solution miracle , encore moins des outils.
quelques pistes :
- faire des find + grep + wc pour trouver la frequence d'utilisation des includes.
- quand l'include n'a besoin que d'un pointeur sur une classe Toto, mettre simplement au debut de l'include
class Toto;
et suprimer l'include "Totot.hh" que l'on reporte dans les cpp qui en ont besoin. Parfois cette simple modification permet de suprimer des dizaines d'includes qui s'appelent les uns les autres.
- avec les compilos modernes les fonctions inline dans les includes sont bcp moins utiles . Ne mettre que celles vraiment indispensables.
- utiliser les namespaces et utiliser "using namespace xxx" pour ne pas avoir a re-ecrire les cpp.
(btw: virer les "using namespace xxx; dans un include , c'est une source de casse-tete futurs)
# demande de précisions
Posté par B. franck . Évalué à 1.
et ce que tu cherches à faire, parce que corriger un include sans savoir la tête/le problème qu'il a ni ce que tu veux en faire: je sais pas faire.
de quel temps de calcul tu parles ? de l'exécutable final ou de la compilation ? (pour l'exécutable final, les includes n'y changeront rien)
# Bête et méchant
Posté par Sylvain Forêt . Évalué à 1.
Un script perl qui fait ça a été proposé sur comp.lang.c++:
http://groups.google.com.au/group/comp.lang.c++/browse_threa(...)
Néanmoins, cette approche n'est pas sans poser quelques problèmes:
+ Elle peut prendre un temps considérable.
+ Certains include peuvent définir des macros qui ne sont pas nécessaires pour compiler mais qui peuvent modifier le comportement du programme.
+ Le résultat est quelque chose qui compile, mais pas forcément la façon la plus élégante et minimaliste de répartir des #include.
Bon courrage !
SF
[^] # Re: Bête et méchant
Posté par Frédéric . Évalué à 1.
J'avoue sourir en y pensant tellement ca parait simpliste de partir d'une idée comme ca. ;) je vais qd meme essayer si j'ai une machine qui ne sert a rien pdt qq temps (quelques semaines) :) (une compilation a 1h15 actuellement en mode debug...)
Je te tiens au courant comment ca se passera. Ca se rajoute du coup dans ma file de projet ;)
tchuss
# ahhh....
Posté par kesako . Évalué à 2.
J'ai souvent ete confronté a ce genre de pb. Il n'y a pas de solution miracle , encore moins des outils.
quelques pistes :
- faire des find + grep + wc pour trouver la frequence d'utilisation des includes.
- quand l'include n'a besoin que d'un pointeur sur une classe Toto, mettre simplement au debut de l'include
class Toto;
et suprimer l'include "Totot.hh" que l'on reporte dans les cpp qui en ont besoin. Parfois cette simple modification permet de suprimer des dizaines d'includes qui s'appelent les uns les autres.
- avec les compilos modernes les fonctions inline dans les includes sont bcp moins utiles . Ne mettre que celles vraiment indispensables.
- utiliser les namespaces et utiliser "using namespace xxx" pour ne pas avoir a re-ecrire les cpp.
(btw: virer les "using namespace xxx; dans un include , c'est une source de casse-tete futurs)
-etc ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.