Comment réduisez-vous le temps de compilation et le temps de liaison pour les projets Visual C ++? (c ++ natif)

Question

Comment réduisez-vous le temps de compilation et le temps de liaison pour les projets VC ++? (C ++ natif)

Veuillez spécifier si chaque suggestion s'applique au débogage, à la publication ou aux deux.

Answer 1

Cela peut sembler évident pour vous, mais nous essayons d'utiliser autant que possible la déclaration forward, même si cela nécessite d'écrire des noms d'espaces de noms longs dans lesquels le (s) type (s) est / sont dans:

 // forward declaration stuff
namespace plotter { namespace logic { class Plotter; } }

// real stuff
namespace plotter {
namespace samples {
    class Window {
        logic::Plotter * mPlotter;
        // ...
    };
}
}
 

Réduit considérablement le temps nécessaire pour compiler également sur d'autres compilateurs. S'applique en effet à toutes les configurations :)

Answer 2

Utilisation de la Poignée/du schéma Corporel (également connu comme "pimpl", "carte", "décorateur", "pont" ou un "wrapper"). En isolant la mise en œuvre de vos classes dans votre .fichiers cpp, ils ont seulement besoin d'être compilé une fois. La plupart des changements ne nécessite pas de modifier le fichier d'en-tête donc, cela signifie que vous pouvez faire d'assez nombreux changements, tout en ne nécessitant qu'un seul fichier pour être recompilé. Cela encourage également refactoring et la rédaction de commentaires et les tests unitaires depuis le temps de compilation est diminué. En outre, vous de séparer automatiquement les préoccupations de l'interface et la mise en œuvre de l'interface de votre code est simplifié.

Answer 3

Si vous avez de grands en-têtes complexes qui doivent être inclus par la plupart des fichiers .cpp dans votre processus de construction et qui ne sont pas modifiés très souvent, vous pouvez les précompiler. Dans un projet Visual C ++ avec une configuration typique, il suffit simplement de les inclure dans stdafx.h. Cette fonctionnalité a ses détracteurs, mais les bibliothèques qui utilisent pleinement les modèles ont généralement beaucoup d'éléments dans les en-têtes, et les en-têtes précompilés sont le moyen le plus simple d'accélérer les générations dans ce cas.

Answer 4

J'utilise Unity Builds (Screencast situé ici ).

Answer 5

Ces solutions s'appliquent à la fois debug et release, et sont axés sur une base de code qui est déjà grand et lourd.

Avant les déclarations sont une solution commune.

Distribué bâtiment, comme avec Incredibuild est une victoire.

Poussant de code à partir des en-têtes vers le bas dans les fichiers source peuvent travailler. Les petites classes, les constantes, les énumérations et ainsi de suite pourrait commencer dans un fichier d'en-tête simplement parce qu'il pourrait avoir été utilisé dans plusieurs unités de compilation, mais en réalité ils ne sont utilisés que dans un seul, et peut être déplacée dans le fichier cpp.

Une solution, je ne l'ai pas lu, mais ont utilisé est de fractionner les grands en-têtes. Si vous avez une poignée de très grands en-têtes, jetez un oeil à eux. Ils peuvent contenir des informations connexes, et peut aussi dépendre de beaucoup d'autres en-têtes. Prendre les éléments qui n'ont pas de dépendances sur d'autres fichiers...simple, les structures, les constantes, les énumérations et les déclarations de l'avant et de les déplacer à partir d' the_world.h de the_world_defs.h. Maintenant, vous pouvez trouver que beaucoup de vos fichiers source peuvent maintenant inclure uniquement the_world_defs.h et d'éviter d'inclure tous les coûts indirects.

Visual Studio dispose également d'un "Spectacle Comprend" qui peut vous donner une idée de la source des fichiers comprennent de nombreux en-têtes et qui fichiers d'en-tête sont le plus souvent inclus.

Pour les très commun comprend, pensez à les mettre dans un en-tête précompilé.