La manipulation stdafx.h à croix-plate-forme de code

Vous êtes le meilleur off à l'aide des en-têtes précompilés pour toujours plus rapide de la compilation.

Vous pouvez utiliser les en-têtes précompilés dans gcc en tant que bien. Voir ici.

La compilation d'en-tête précompilé aura une extension ajouté que .gch au lieu de .pch.

Par exemple, si vous précompiler stdafx.h vous aurez un fichier d'en-tête qui sera automatiquement recherchées appelé stdafx.h.gch à tout moment vous d'inclure stdafx.h

Exemple:

stdafx.h:

#include <string>
#include <stdio.h>

a.cpp:

#include "stdafx.h"
int main(int argc, char**argv)
{
  std::string s = "Hi";
  return 0;
}

Puis compilez comme:

> g++ -c stdafx.h -o stdafx.h.gch

> g++ a.cpp

> ./a.out

Votre compilation fonctionne même si vous supprimez stdafx.h après l'étape 1.

J'avais soit aller pour l'option 4 option 2 ou les deux. J'ai expérimenté avec les en-têtes précompilés sur divers VS versions et GCC sous Linux (posts à ce sujet ici et ici). Dans mon expérience, VS est beaucoup plus sensible à la longueur des chemins d'inclusion, le nombre de répertoires dans le chemin d'inclusion, et le nombre de fichiers à inclure de G++. Lorsque j'ai mesuré les temps de construire correctement disposés les en-têtes précompilés serait faire une énorme différence au moment de la compilation sous VS alors que G++ été très impressionné par cette.

En fait, fondée sur le dessus de ce que j'ai fait la dernière fois que j'ai travaillé sur un projet où cela a été nécessaire de réduire le temps de compilation a été précompiler l'équivalent de stdafx.h sous Windows où il fait sens et tout simplement utilisé comme un fichier normal sous Linux.

Je tiens seulement à utiliser l'option 1 dans une grande équipe de développeurs.
Les Options 2, 3, et 4, seront souvent interrompre la productivité des autres membres de votre équipe, donc vous peut sauver quelques minutes par jour au moment de la compilation.

Voici pourquoi:

Supposons que la moitié de vos développeurs utilisent VS et la moitié d'utiliser gcc.
Chaque maintenant et puis certains VS développeur oubliez pas d'inclure un en-tête dans un .fichier cpp.
Il ne sera pas d'avis, parce que le stdafx.h comprend implicitement il. Donc, il pousse ses changements dans le contrôle de version, et puis quelques autres membres de l'équipe de gcc obtiendrez des erreurs du compilateur.
Donc, pour toutes les 5 minutes par jour vous gagnez en utilisant les en-têtes précompilés, 5 autres personnes de déchets par la fixation de votre manquants en-têtes.

Si vous ne partagez pas le même code sur l'ensemble de vos compilateurs, vous serez confronté à des problèmes comme ça tous les jours. Si vous forcez votre VS développeurs de vérifier pour la compilation de gcc avant de pousser des changements, puis vous jetez tous vos gains de productivité en utilisant les en-têtes précompilés.

Option 4 semble intéressant, mais que faire si vous souhaitez utiliser un autre compilateur à un certain point dans le temps ? Option 4 ne fonctionne que si vous utilisez uniquement VS et de la gcc.

Avis que l'option 1 pourrait faire de la compilation de gcc souffrir de quelques secondes. Bien qu'il ne soit pas perceptible.

Depuis stdafx.h est, par défaut, toutes les Fenêtres spécifique des choses, j'ai mis un vide stdafx.h sur mon autre plate-forme. De cette façon, votre code source reste identique, tout en désactivant stdafx sur Linux sans avoir à enlever toutes les #include "stdafx.h" lignes à partir de votre code.

Je l'ai fait à la fois l'option 2 (#ifdef) et l'option 4 (PCH pour gcc) pour la croix-plate-forme de code avec pas de problèmes.

Je trouve gcc compile beaucoup plus rapide que VS si les en-têtes précompilés sont généralement pas si important que cela, à moins que vous ne fassiez référence à un énorme fichier d'en-tête.