C/C++ inclure le fichier de commande/de meilleures pratiques

Question

Est-il recommandé ordre dans lequel les fichiers à inclure doit être spécifié?

Par exemple, le système de fichiers STL, Boost, aller de l'avant de l'après locales inclure des fichiers? Est-il une raison particulière de choisir l'un ou l'autre? Je suis en supposant inclure des fichiers, qui ont leurs propres dépendances spécifiées.

Answer 1

Je ne pense pas qu'il y a un ordre recommandé, tant que ça compile! Ce qui est ennuyeux, c'est quand certains en-têtes exiger que d'autres en-têtes inclus en premier... C'est un problème avec les en-têtes eux-mêmes, pas à l'ordre du comprend.

Ma préférence personnelle est de passer du local au global, chaque paragraphe dans l'ordre alphabétique, c'est à dire:

1. h fichier correspondant à ce fichier cpp (le cas échéant)
2. les en-têtes d'un même composant,
3. les en-têtes des autres composants,
4. système d'en-têtes.

Mon raisonnement pour 1. c'est qu'il doit prouver que chaque en-tête (pour lequel il existe un rpc) peuvent être #included sans conditions préalables. Et le reste semble découler logiquement à partir de là.

Answer 2

La chose importante à garder à l'esprit que vos en-têtes ne doivent pas être dépendant des autres en-têtes inclus en premier. Une manière de s'assurer d'inclure votre les en-têtes avant tous les autres en-têtes.

"Penser en C++" mentionne notamment ce, référencement Lakos' "à Grande Échelle en C++ de Logiciels de Conception":

Latente les erreurs d'utilisation peut être évité en s'assurant que l' .h fichier d'un composant analyse par lui-même – sans de l'extérieur de déclarations ou de définitions... y Compris la .h fichier que la première ligne de la .c fichier s'assure qu'aucun élément d'information intrinsèque à l'interface physique du composant est manquant dans le .h de fichier (ou, s'il en est, que vous trouverez à ce sujet dès que vous essayez de compiler le .c fichier).

C'est-à-dire dans l'ordre suivant:

1. Le prototype de l'interface de l'en-tête de cette mise en œuvre (c'est à dire, le .h/.hh fichier qui correspond à cela .rpc/.cc fichier).
2. D'autres en-têtes d'un même projet, en tant que de besoin.
3. Les en-têtes des autres non-standard, non-système de bibliothèques (par exemple, Qt, Propres, etc).
4. Les en-têtes des autres "presque " standard" des bibliothèques (par exemple, Boost)
5. Standard C++ en-têtes (par exemple, iostream, fonctionnel, etc)
6. La norme C-têtes (par exemple, cstdint, dirent.h, etc)

Si l'un des en-têtes ont un problème avec le fait d'être inclus dans cet ordre, les corriger (si le vôtre) ou ne pas les utiliser. Boycott des bibliothèques qui n'écrivent pas de nettoyer les en-têtes.

Google C++ style guide (http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml) soutient presque l'inverse, avec pas vraiment de justification à tous; j'ai personnellement tendance à favoriser la Lakos approche.

Answer 3

J'ai suivi deux règles simples qui permettent d'éviter la grande majorité des problèmes:

1. Tous les en-têtes (et de fait, tous les fichiers source) devrait inclure ce dont ils ont besoin. Ils doivent pas compter sur leurs utilisateurs, y compris les choses.
2. En complément, tous les en-têtes doivent avoir des gardes afin de ne pas avoir inclus de multiples reprises par les plus ambitieux de l'application de la règle 1 ci-dessus.

J'ai aussi suivi les lignes directrices de:

1. Inclure les en-têtes systèmes premier (stdio.h, etc) avec une ligne de démarcation.
2. Groupe de façon logique.

En d'autres termes:

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

#include "btree.h"
#include "collect_hash.h"
#include "collect_arraylist.h"
#include "globals.h"

Bien que, étant des lignes directrices, c'est une chose subjective. Les règles sur l'autre main, j'ai appliquer de manière rigide, même au point de fournir des 'wrapper' fichiers d'en-tête à inclure des gardes et regroupés comprend si certains odieux développeur tiers n'est pas à vous abonner à ma vision des choses :-)

Answer 4

Pour ajouter ma propre brique dans le mur.

1. Chaque en-tête doit être auto-suffisante, qui ne peut être vérifiée que si au moins une fois qu'il est inclus en premier
2. Il ne faut pas tort de modifier le sens d'un 3ème partie de l'en-tête par l'introduction de symboles (macro, types, etc...)

J'ai donc l'habitude d'aller, comme ceci:

// myproject/src/example.cpp
#include "myproject/example.h"

#include <algorithm>
#include <set>
#include <vector>

#include <3rdparty/foo.h>
#include <3rdparty/bar.h>

#include "myproject/another.h"
#include "myproject/specific/bla.h"

#include "detail/impl.h"

Chaque groupe séparé par une ligne vide de la suivante:

• L'en-tête correspondant à ce fichier cpp première (sanity check)
• système d'en-têtes
• 3ème partie-têtes, organisé par l'ordre des dépendances
• projet les en-têtes
• projet privé, les en-têtes

Notez également que, hormis le système d'en-têtes de chaque fichier est dans un dossier avec le nom de son espace de noms, juste parce que c'est plus facile à retrouver pour cette façon.

Answer 5

Je recommande:

1. L'en-tête de pour la .cc module vous êtes en train de construire. (Aide à s'assurer que chaque en-tête de votre projet n'a pas de dépendances implicites sur les autres en-têtes dans votre projet).
2. C système de fichiers.
3. C++ système de fichiers.
4. De plate-forme / OS / autres fichiers d'en-tête (par exemple, win32, gtk, openGL).
5. D'autres fichiers d'en-tête de votre projet.

Et bien sûr, l'ordre alphabétique au sein de chaque section, lorsque cela est possible.

Utilisez toujours de l'avant déclarations afin d'éviter d'inutiles #includes dans vos fichiers d'en-tête.