La raison [1] plus Rapide temps de compilation
Pas dans mes projets: les fichiers source (RPC) ne comprennent que les en-têtes (HPP) dont ils ont besoin. Donc quand j'ai besoin de recompiler un seul RPC en raison d'un changement minuscule, j'ai dix fois le même nombre de fichiers qui ne sont pas recompilés.
Vous devriez peut-être briser votre projet plus logique sources/en-têtes: Une modification dans la classe A de la mise en œuvre ne devrait PAS avoir besoin de la recompilation des implémentations de classe B, C, D, E, etc..
La raison[2]. Il évite les dépendances circulaires
Les dépendances circulaires dans le code?
Désolé, mais je n'ai pas encore eu ce genre de problème à un problème réel: disons que A dépend de B, et B dépend de A:
struct A
{
B * b ;
void doSomethingWithB() ;
} ;
struct B
{
A * a ;
void doSomethingWithA() ;
} ;
void A::doSomethingWithB() { /* etc. */ }
void B::doSomethingWithA() { /* etc. */ }
Une bonne façon de résoudre le problème serait de briser cette source dans au moins une source de/en-tête de chaque classe (de manière similaire à Java, mais avec une seule source et un seul en-tête de chaque classe):
// A.hpp
struct B ;
struct A
{
B * b ;
void doSomethingWithB() ;
} ;
.
// B.hpp
struct A ;
struct B
{
A * a ;
void doSomethingWithA() ;
} ;
.
// A.cpp
#include "A.hpp"
#include "B.hpp"
void A::doSomethingWithB() { /* etc. */ }
.
// B.cpp
#include "B.hpp"
#include "A.hpp"
void B::doSomethingWithA() { /* etc. */ }
Ainsi, pas de problème de dépendance, et encore rapide temps de compilation.
Ai-je raté quelque chose?
Lorsque l'on travaille sur le "monde réel" des projets
dans un monde réel projet, les fichiers cpp ont tendance à inclure des en-têtes jusqu'à ce que vous ne pouvez pas comprendre qui dépend pour qui
Bien sûr. Mais alors, si vous avez le temps de réorganiser les fichiers pour construire votre "un RPC" solution, alors vous avez le temps de nettoyer les têtes. Mes règles pour les en-têtes sont:
- briser en-tête pour les rendre aussi modulaire que possible
- Ne jamais inclure les en-têtes que vous n'avez pas besoin
- Si vous avez besoin d'un symbole, de l'avant-déclarer
- seulement si le ci-dessus a échoué, inclure l'en-tête
De toute façon, tous les en-têtes doivent être auto-suffisante, qui signifie:
- Un en-tête comprennent tous besoin des en-têtes (et nécessaire uniquement les en-têtes - voir ci-dessus)
- un vide fichier CPP dont un en-tête doit compiler sans avoir besoin d'inclure quoi que ce soit d'autre
Cela permettra d'éliminer la commande de problèmes et les dépendances circulaires.
Est temps de compilation d'un problème? Alors...
Devrait moment de la compilation être vraiment un problème, je voudrais envisager:
- En utilisant les en-têtes précompilés (ce qui est assez utile pour les STL et BOOST)
- Diminuer le couplage à travers le PImpl idiome, comme expliqué dans http://en.wikipedia.org/wiki/Opaque_pointer
- L'utilisation partagée en réseau compilation
Conclusion
Ce que vous faites est de ne pas tout mettre dans les en-têtes.
Vous êtes fondamentalement, y compris tous vos fichiers en une seule et unique source final.
Peut-être que vous êtes en train de gagner dans des conditions de pleine-projet de compilation.
Mais lors de la compilation pour un petit changement, vous aurez toujours perdre.
Lors du codage, je sais que je compile souvent de petits changements (si ce n'est que le compilateur valider mon code), puis un dernier temps, faire un changement de projet.
Je voudrais perdre beaucoup de temps si mon projet a été organisée à votre façon.
