Discussion :

[Pyramidev]

Actuellement, la réponse écrite dans la FAQ est la suivante :

1. Le fichier d'en-tête de la déclaration de la classe ;
2. les fichiers standards (STL) ;
3. les fichiers d'en-tête de l'O.S. ;
4. les fichiers d'en-tête des bibliothèques tierces (boost, xml, wxWidget…) ;
5. les fichiers d'en-tête de mes bibliothèques externes ;
6. les fichiers d'en-tête de mon projet.

Cet ordre est une proposition parmi d'autres qui ont aussi leur légitimité. Vous pouvez suivre un autre ordre d'inclusion si vous en sentez le besoin compte tenu de vos pratiques habituelles ou du contexte de votre application. En fait, l'idée maîtresse est de maintenir une cohérence sur l'ensemble du projet. Quelle que soit la politique que vous choisissez de mettre en ouvre, utilisez la même systématiquement dans tous vos fichiers.

Lien : http://cpp.developpez.com/faq/cpp/?p...iers-d-en-tete

Je suis en désaccord avec cette réponse et je propose la réponse suivante :

Dans un fichier ".cpp", par exemple "Toto.cpp", inclure dans l'ordre :

1. un éventuel entête précompilé (par exemple "stdafx.h" si vous utilisez Visual C++) ;
2. le fichier d'entête de la déclaration de la classe (typiquement "Toto.h") ;
3. les fichiers d'entête du projet ;
4. les fichiers d'entête du groupe de projets ;
5. les fichiers d'entête des bibliothèques externes ;
6. les fichiers d'entête des bibliothèques tierces qui incluent des entêtes de l'OS ;
7. les fichiers d'entête de l'O.S. ;
8. les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS ;
9. les fichiers standards (STL) ;

Dans un entête, par exemple "Toto.h", inclure dans l'ordre :

1. les fichiers d'entête du projet ;
2. les fichiers d'entête du groupe de projets ;
3. les fichiers d'entête des bibliothèques externes ;
4. les fichiers d'entête des bibliothèques tierces qui incluent des entêtes de l'OS ;
5. les fichiers d'entête de l'O.S. ;
6. les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS ;
7. les fichiers standards (STL) ;

L'idée est d'aller du plus local vers le plus général pour maximiser les chances de détecter les oublis dans les entêtes.

Par exemple, admettons que "Toto.h" ait besoin d'inclure "Titi.h", un entête du même projet, mais a oublié de le faire. Pour que l'erreur soit détectée, il suffit qu'un fichier ".cpp" inclut (directement ou indirectement) "Toto.h" avant d'inclure "Titi.h".
Si "Toto.cpp" inclut "Toto.h" juste après avoir inclus l'éventuel entête précompilé alors, le seul cas où l'erreur n'est pas détectée, c'est celui où l'éventuel entête précompilé inclut "Titi.h".

Pour prolonger l'exemple, admettons que "Toto.h" ait besoin d'inclure, en plus de "Titi.h" (un entête du même projet), "Groupe.h", un entête du même groupe de projets. Admettons aussi que "Titi.h" ait besoin d'inclure lui aussi "Groupe.h" mais a oublié de le faire, et que le "Titi.cpp" ne suive pas les conventions d'inclusions et inclut "Groupe.h" avant d'inclure "Titi.h", ce qui masque l'erreur.
Si "Toto.h" inclut les entêtes du projet avant ceux du groupe de projets, donc inclut "Titi.h" avant d'inclure "Groupe.h", l'erreur sera détectée à la compilation de "Toto.cpp", sauf si "Groupe.h" appartient à l'éventuel entête précompilé inclus par "Toto.cpp".

Remarque : S'il n'y a aucun entête précompilé, il suffit que chaque fichier ".cpp" inclut en premier son fichier d'entête correspondant pour que la compilation garantisse qu'il ne manque aucune inclusion et aucune déclaration dans les fichiers d'entête.

EDIT 19/09/2016 vers 14h46 : En fait, l'ordre entre "les fichiers d'entête de l'O.S." et "les fichiers d'entête des bibliothèques tierces qui n'incluent aucun entête de l'OS" n'a pas d'importance, tant que aucun ne fait des inclusions de l'autre.

[jo_link_noir]

Cet ordre me semble plus approprié pour la même raison que mentionné: maximiser les chances de détecter les oublis dans les entêtes.

Par contre, je ne comprends pas les différences entre les en-têtes de bibliothèques tierces, externes et OS.

[Pyramidev]

J'avoue que je ne suis pas certain du sens que l'auteur donnait à "bibliothèques externes".
Et c'est vrai que l'ordre des en-têtes de bibliothèques tierces et OS n'est pas important.

J'aurais peut-être dû écrire :

1. un éventuel entête précompilé (par exemple "stdafx.h" si vous utilisez Visual C++) ;
2. le fichier d'entête de la déclaration de la classe (typiquement "Toto.h") ;
3. les fichiers d'entête du projet ;
4. les fichiers d'entête du groupe de projets ;
5. les fichiers d'entête des bibliothèques tierces (boost, xml, wxWidget…) et les fichiers d'entête de l'O.S. ;
6. les fichiers standards (STL) ;

[JolyLoic]

Personellement, je fais plutôt :
- Le truc pour les entêtes précompilés le cas échéant
- L'entête du .h correspondant au .cpp le cas échéant
- Le reste dans le désordre

Ainsi, je maximise encore plus les détections de problèmes que vous, puisque je teste une combinatoire plus grande

[Pyramidev]

Ainsi, je maximise encore plus les détections de problèmes que vous, puisque je teste une combinatoire plus grande

Non car les bibliothèques tierces n'ont pas besoin d'inclure les entêtes du groupe de projet et les entêtes du groupe de projets n'ont pas besoin d'inclure les entêtes spécifiques au projet.

Le seul cas où on détecte un oubli, c'est quand on inclut (directement ou indirectement) "A.h" avant "B.h" et que "A.h" avait oublié d'inclure "B.h".

Par contre, à l'intérieur d'un même groupe d'entêtes, par exemple les entêtes du groupe de projet, j'avoue avoir tendance à tout mettre dans l'ordre alphabétique alors que, pour maximiser les détections d'oubli, il faudrait les mettre dans le désordre ou, encore mieux, du plus haut niveau au plus bas niveau (à supposer que ce ne soit pas du code spaghetti).

[JolyLoic]

Il n'y a pas que l'oubli à tester, mais il y a aussi la pollution des macros...

Vivement les modules !!