Optimisations des includes

Bonjour à tous ;),

Je voulais savoir si il était possible d'optimiser les includes dans un projet autrement qu'en faisant des forward declarations un peu partout :D.

En fait disons le plus clairement j'ai une classe mère dont héritent plusieurs classes dérivées dont les déclarations sont situées à chaque fois dans un .hpp différent.
Le problème étant que l'accès à la totalité de ces classes est sensé pouvoir se faire, donc pour cela et dans l'état actuel des choses je suis obligé de passer par un fichier .hpp regroupant les includes de tous les fichiers .hpp des classes dérivées.
Or ce n'est vraiment pas très pratique puisque je serai souvent amené à ajouter des classes dérivées de la classe mère ci-dessus et donc à compléter le fichier regroupant tous les includes !

Y a-t-il une solution pour pallier ce problème ?

Merci par avance :ccool:

Bonsoir,

à vue de nez la meilleure solution serait de revoir l'architecture qui semble, au mieux, bancale.

Favoriser les forward declaration dans les header n'a qu'une incidence sur la vitesse de compilation de toutes façons. Bien que ça peut être intéressant pour un gros projet et permettre de gagner de précieuses minutes de compilation.

Il y a aussi les header précompilés qui peuvent être utilisés.

Bonjour,

Je ne comprend pas l'intérêt du regroupement. Quand tu utilises une classe dérivé alors tu les utilises toute ? Si c'est le cas, en effet, un regroupement a un intérêt, mais il y a surment un gros problème de conception (non respect du SRP). Sinon, pourquoi regrouper ? J'ai besoin d'une classe je fais une déclaration anticpée ou un include, quel intérêt d'inclure toute un groupe si j'en utilise qu'une.

Sauf si effectivement tu codes une bibliothèque ... mais dans ce cas, le gros fichier est requis.

Par exemple, jette un œil sur le fichier <map> de la STL de g++, c'est d'un joli tout plein...

Ce que fait l'implémentation de GCC ça n'a pas d'importance, la norme indique ce que doit contenir le fichier <map> comme interface : map, multimap et les opérations associées, je ne trouve pas ça excessif, c'est un ensemble cohérent d'éléments.

Cependant je suis d'accord avec toi, lors de l'écriture d'une bibliothèque il arrive de fournir un fichier d'include qui fait plusieurs include pour offrir de quoi faire les utilisations les plus courante avec qu'une seule include. C'est ce que fait boost typiquement. Par contre ça n'amène aucun problèmes : ça se fait indépendamment du reste.

Merci pour vos réponses ;)

Il s'agit peut-être d'un problème de design. Je vais regarder ça de plus près.

Edit : en fait je suis un ****cile :D je n'ai absolument pas besoin d'inclure toutes les classes dérivées seulement l'include du fichier de la classe mère est utile.

Désolé pour la perte de temps, sujet inutile mais résolu :mouarf: