Ordre des en-têtes C ++

Question

Dans quel ordre les en-têtes doivent-ils être déclarés dans un fichier d'en-tête / cpp? Évidemment, ceux qui sont requis par les en-têtes suivants devraient être antérieurs et les en-têtes spécifiques à la classe devraient être dans la portée cpp et non dans la portée d'en-tête, mais y a-t-il une convention d'ordre défini / meilleure pratique?

Answer 1

Dans un fichier d'en-tête, vous devez inclure TOUS les en-têtes pour le rendre compilable. Et n'oubliez pas d'utiliser des déclarations avancées au lieu de certains en-têtes.

Dans un fichier source:

• fichier d'en-tête correspondant
• en-têtes de projet nécessaires
• En-têtes de bibliothèques tierces
• en-têtes de bibliothèques standard
• en-têtes du système

Dans cet ordre, vous ne manquerez aucun de vos fichiers d'en-tête qui ont oublié d'inclure les bibliothèques par eux-mêmes.

Answer 2

Bonne pratique: chaque .h fichier doit avoir une .rpc qui comprend .h premier avant toute autre chose. Cela prouve que tout .h fichier peut être mis en premier.

Même si l'en-tête nécessite pas de mise en œuvre, de vous faire une .rpc qui comprend juste que .h fichier et rien d'autre.

Ensuite, cela signifie que vous pouvez répondre à votre question de la manière que vous souhaitez. Il n'a pas d'importance quel ordre vous les inclure dans.

Pour plus de conseils, essayez ce livre: à Grande Échelle en C++ de Logiciels de Conception - c'est une honte tellement c'est cher, mais c'est pratiquement un guide de survie pour le code source C++ de mise en page.

Answer 3

Dans les fichiers d'en-tête, j'ai tendance à mettre des en-têtes standard d'abord, puis mes propres en-têtes (les deux listes sont ordonnés dans l'ordre alphabétique). Dans la mise en œuvre des fichiers, j'ai mis d'abord l'en-tête correspondant (le cas échéant), puis les normes en-têtes et autres dépendances-têtes.

L'ordre est de peu d'importance, sauf si vous en faites une grande utilisation de macros et d' #define ; dans ce cas, vous devez vérifié une macro que vous avez défini ne remplace pas un déjà inclus (sauf si c'est ce que vous voulez, bien sûr).

Concernant la présente déclaration

ceux qui sont requis par les en-têtes doivent être plus tôt

Un en-tête ne doit pas reposer sur les autres en-têtes inclus avant! Si elle nécessite des en-têtes, il comprend entre eux. En-tête de gardes de prévenir plusieurs inclusion:

#ifndef FOO_HEADER_H
#define FOO_HEADER_H
...
#endif

---

MODIFIER

Depuis que j'ai écrit cette réponse, j'ai changé ma façon de commander les directives include dans mon code. Maintenant, j'essaie de toujours mettre des en-têtes dans l'ordre croissant de la normalisation, de sorte que les en-têtes de mon projet de venir en premier, suivi par le 3e partie-têtes des bibliothèques, suivie par des en-têtes standard.

Par exemple, si l'un de mes fichier utilise une bibliothèque que j'ai écrit, Qt, Boost et de la bibliothèque standard, je vais commander le comprend comme suit:

//foo.cpp
#include "foo.hpp"

#include <my_library.hpp>
// other headers related to my_library

#include <QtCore/qalgorithms.h>
// other Qt headers

#include <boost/format.hpp> // Boost is arguably more standard than Qt
// other boost headers

#include <algorithms>
// other standard algorithms

La raison pour laquelle je fais cela est de détecter les dépendances manquantes dans mon propre en-têtes: supposons par exemple que l' my_library.hpp utilise std::copy,, mais ne comprennent pas <algorithm>. Si je comprend après l' <algorithm> en foo.cpp, cette dépendance manquante passeront inaperçus. Au contraire, avec la commande, j'ai juste présenté, le compilateur va se plaindre qu' std::copy n'a pas été déclarée, ce qui me permet de corriger my_library.hpp.

Dans chaque "bibliothèque" du groupe, j'essaie de garder les directives include classés par ordre alphabétique, pour les trouver plus facilement.

Sur une note, une bonne pratique est également de limiter au maximum les dépendances entre les fichiers d'en-tête. Les fichiers doivent inclure aussi peu en-têtes que possible, en particulier les en-têtes de fichier. En effet, plus les en-têtes de vous comprendre, le plus, le code doit être recompilé lorsque quelque chose change. Un bon moyen de limiter ces dépendances est à utiliser avant la déclaration, ce qui est très souvent suffisant dans les fichiers d'en-tête (voir Quand utiliser la déclaration anticipée?).

Answer 4

Google C++ Guide de Style, les Noms et l'Ordre des Comprend :

Dir/foo.cc, dont le but principal est de mettre en œuvre ou de tester les trucs en dir2/foo2.h, de l'ordre de votre comprend comme suit:

• dir2/foo2.h (emplacement de choix - voir détails ci-dessous).
• C système de fichiers.
• C++ système de fichiers.
• D'autres bibliothèques .h fichiers.
• De votre projet .h fichiers.

Answer 5

Je les commandais par ordre alphabétique (plus facile à trouver)