Discussion :

[FroZman]

Cela fait un certain temps que je me pose cette question:

• Existe-t-il une convention "propre" ou au moins plus logique que d'autres, en ce qui concerne les includes dans les fichiers de header ?

J'ai pris l'habitude de déclarer les fonctions/classes/structures dans des fichiers séparés (.hh / .hxx) de leur implémentation (.cc), mais d'un projet à l'autre je n'arrive jamais à déterminer ce qui est le plus propre à savoir entre mettre tous les includes nécessaires à la déclaration dans les headers, ou alors les mettre dans les .cc ce qui implique de faire des définitions locales vides dans les headers ("Class Toto;" par exemple).

Et vous ? Vous gérer ça comment ?

Avec des templates ça devient encore plus complexe, quelles sont les règles de base avec les includes et les classes templatées ?

Je précise que ça n'a rien de vital, mais si je pouvais ne plus à avoir à me poser cette question à chaque fois que j'attaque un nouveau projet, ça me soulagerait.

Merci par avance !

[3DArchi]

Bonjour,

Cela fait un certain temps que je me pose cette question:

• Existe-t-il une convention "propre" ou au moins plus logique que d'autres, en ce qui concerne les includes dans les fichiers de header ?

Je ne sais pas s'il existe des 'conventions' ou des pratiques établies. Au travers de mes différentes expériences, j'ai vu différents cas, donc j'aurais tendance à penser que non.
Je peux te préciser comment j'essaie de faire moi, sans que cela ne soit bien sûr une meilleure pratique qu'une autre

J'ai pris l'habitude de déclarer les fonctions/classes/structures dans des fichiers séparés (.hh / .hxx) de leur implémentation (.cc), mais d'un projet à l'autre je n'arrive jamais à déterminer ce qui est le plus propre à savoir entre mettre tous les includes nécessaires à la déclaration dans les headers, ou alors les mettre dans les .cc ce qui implique de faire des définitions locales vides dans les headers ("Class Toto;" par exemple).

Et vous ? Vous gérer ça comment ?

Je sépare mes déclarations (.h) des mes définitions (.cpp). Dans les fichiers d'en-têtes .h, je mets des déclarations anticipées (class Toto; ) dès que je le peux et je ne met l'include que dans le .cpp.
Une excpetion : quand je souhaite à travers du même .h publier une interface de plusieurs classes. Exemple : un contrôle wxWidget avec les wxEvent qui vont avec : le fichier d'en-tête du contrôle fait un include du fichier d'en-tête de l'évènement car l'utilisation des deux classes va de pair : l'utilisateur de la classe du contrôle devra récupérer les évènements associés.
Dans le fichier source, j'inclus les fichiers d'en-tête dans cet ordre :
1/ Le fichier d'en-tête de la déclaration de la classe
2/ Les fichiers d'en-tête de mon projet
3/ Les fichiers d'en-tête de mes bibliothèques externes
4/ Les fichiers d'en-tête des bibliothèques tierces (boost, xml, windows, wxWidget, ...)
5/ Les fichiers standards (stl).
En cas d'en-têtes précompilés, j'essaie de tirer bénéfice de la précompilation au maximum en mettant les en-têtes des bibliothèques tierces et externes dans l'en-tête précompilé... ce qui change l'ordre présenté ci-dessus.
Parfois il me faut bousculer ceci car tous n'est pas parfait et des dépendances l'obligent

Avec des templates ça devient encore plus complexe, quelles sont les règles de base avec les includes et les classes templatées ?

Pour les templates simples (...), tout est dans le même fichier .h
Pour les templates plus complexes, je n'hésite pas à séparer déclaration et définition (comme expliqué dans la FAQ). Je sépare aussi quand un template s'appuie sur des classes traits/politiques ou autre. J'essaie de garder au maximum un fichier==une classe (au moins quelque chose d'atomiquement cohérent).

Je précise que ça n'a rien de vital, mais si je pouvais ne plus à avoir à me poser cette question à chaque fois que j'attaque un nouveau projet, ça me soulagerait.

Merci par avance !

Comme dit au début, je ne sais pas s'il existe de bonnes pratiques établies. Je dirais que le mieux est quand même que le choix opéré soit constant dans tous le projet. Le pire étant d'avoir de multiples pratiques dans le même projet : cela rend la lecture du code et la recherche d'informations confuses.

[LittleWhite]

Bonjour,

J'ajouterai que les déclarations anticipées dans le .hpp sont a preconiser. Car cela evite que les classe incluse ne soit visible dans trop d'autre fichier quand on inclut le .hpp
De plus, il se peut qu'il est des conflits ( inclusion de deux fois la même fonction ) sans cette technique.

[FroZman]

Je sépare mes déclarations (.h) des mes définitions (.cpp). Dans les fichiers d'en-têtes .h, je mets des déclarations anticipées (class Toto; ) dès que je le peux et je ne met l'include que dans le .cpp.

C'est ce que j'ai tendance à faire, le gros problème c'est avec les templates.

Pour les templates simples (...), tout est dans le même fichier .h
Pour les templates plus complexes, je n'hésite pas à séparer déclaration et définition (comme expliqué dans la FAQ). Je sépare aussi quand un template s'appuie sur des classes traits/politiques ou autre. J'essaie de garder au maximum un fichier==une classe (au moins quelque chose d'atomiquement cohérent).

Personnellement, je pars du principe que les fichiers de déclaration de classe ne devraient contenir QUE les entêtes et la documentation associée.

Avec bien sûr, une unique classe par fichier. Sinon on a vite fait de s'y perdre.

Comme dit au début, je ne sais pas s'il existe de bonnes pratiques établies. Je dirais que le mieux est quand même que le choix opéré soit constant dans tous le projet. Le pire étant d'avoir de multiples pratiques dans le même projet : cela rend la lecture du code et la recherche d'informations confuses.

Oui, c'est bien le principal problème. Il me parait également très important de fixer dès le départ une convention commune, le tout étant d'arriver à mettre tout le monde d'accord, ce qui passe par le choix d'une convention dont la "logique" servirait de justificatif et ferait donc foi face à des préférences personnelles souvent immotivées.

Bonjour,
J'ajouterai que les déclarations anticipées dans le .hpp sont a preconiser. Car cela evite que les classe incluse ne soit visible dans trop d'autre fichier quand on inclut le .hpp

Je crois que nous sommes tous les 3 d'accord sur ce point. C'est un bon début.

De plus, il se peut qu'il est des conflits ( inclusion de deux fois la même fonction ) sans cette technique.

Là par contre je ne vois pas comment c'est possible si tu utilises la technique du:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
#ifndef TOTO_HH
# define TOTO_HH
 
/// ...
 
#endif /* !TOTO_HH */

[loufoque]

Il n'y a qu'une règle de bon sens et hyper simple :

Dans chaque fichier, tu dois inclure le strict minimum pour que tout ce dont tu as besoin soit déclaré ou défini (histoire que le fichier puisse compiler...).

[FroZman]

Il n'y a qu'une règle de bon sens et hyper simple :

Dans chaque fichier, tu dois inclure le strict minimum pour que tout ce dont tu as besoin soit déclaré ou défini (histoire que le fichier puisse compiler...).

Là on en est à inclure moins que le strict minimum à cause des déclarations de classes réciproques (class Toto utilise class Titi qui elle même utilise class Toto).

[befalimpertinent]

Amha, j'aurai tendance à penser comme Loufoque : chaque fichier inclut ce qui lui est nécessaire pour compiler sans ce soucier de savoir si tel ou tel fichier inclut déjà une entête utilisé.
Je pousse même le vice jusqu'à inclure deux fois les fichiers s'ils sont utilisé dans le .h et le .cpp:
Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
//fichier.h
#include <vector>
class A
{
std::vector<int> tab;
};

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
//fichier.cpp
#include <vector> //en incluant d'abord les fichier du compilo (STL)
//puis eventuellement les lib externes (Boost, ma_lib_a_moi)
#include "fichier.h" //et enfin les fichiers du projet en cours

[JolyLoic]

J'applique les mêmes critères :
- Tout fichier .h doit pouvoir être inclus indépendamment de tout le reste, et ça doit compiler
- Tout fichier .h doit contenir le moins de choses possibles.

Pour vérifier le premier point, j'utilise une astuce : J'inclus le .h associé à un .cpp en tout premier dans ce .cpp : ainsi, je suis certain qu'il y a au moins un endroit dans le code où chaque .h est inclus sans pré-requis, et donc qu'ils sont tous autonomes.

Là on en est à inclure moins que le strict minimum à cause des déclarations de classes réciproques (class Toto utilise class Titi qui elle même utilise class Toto).

Le minimum, c'est d'utiliser des forward declaration, plutôt que des include, à chaque fois qu'une forward declaration suffit.

[FroZman]

J'inclus le .h associé à un .cpp en tout premier dans ce .cpp : ainsi, je suis certain qu'il y a au moins un endroit dans le code où chaque .h est inclus sans pré-requis, et donc qu'ils sont tous autonomes.

Pas bête, ça bouscule un peu les conventions en incluant un headed personnel plutôt que les headers de la STL en premier, mais ça ne mange pas de pain et à première vu je ne vois pas de contre-indications.