Discussion :

[KonTiKI]

Bonjour à tous.

Je n'arrive pas à trouver une réponse pour cette question : Existe-t-il une règle pour placer les directives #include <> ou #include" ".

Faut-il les mettre dans l'entête plutôt que dans le source ?

Faut-il les mettre là où la fonction est appelée ?

Cette dernière solution me semblerait logique, sauf si le compilateur en a besoin avant.

J'ai fait de simple test, mais dans les deux cas ça fonctionnait. Bref vous comprenez que je suis un peu hésitant.

Merci pour votre point de vue.

[foetus]

C'est plus difficile que cela et on peut avoir des problèmes (des "choses" non déclarées ou déclarées plusieurs fois)

Parce que, lorsque tu inclus une entêtre, tu inclus en même temps les entêtes qui sont dans l'entête.

Tu as donc un arbre d'inclusion , et il faut faire attention à ce que dans cet arbre tu n'es qu'une seule fois une entête [dans un sous arbre]

Après si tu appelles plusieurs fois une entête, tu as les include guards qui protègent.

Et enfin, j'évite de mettre trop d'include dans les entêtes et je fais des "forward declaration" (déclaration anticipée *) à la place, si c'est possible.


* -> Merci Médinoc

[bacelar]

Tu peux faire ce que tu veux, l'include, c'est juste mettre le contenu d'un fichier dans un autre.
Le pré-processeur fera ce que tu demandes.

MAIS, faut pas faire nimportenawak juste parce que personne ne te l'interdit.

Il faut rendre ton code maintenable.

Et le plus simple, et de loin, pour qu'il reste maintenable, c'est de mettre les includes au début du fichier.

L'ordre des includes est aussi très important.

On commence par les includes des librairies "globales" comme celles des librairies graphiques, des librairies d'accès aux données, etc..., pour savoir rapidement à quelle partie/module de l'application le code lié.
(On utilise des <> pour ce type d'include)

On suit par les includes des classes du projet/module du projet qui doivent être connues par le code de fichier, pour savoir les interdépendances entre ce fichier et les autres éléments du même module.
(On utilise des "..." pour ce type d'include)

On finit avec les includes "domestiques" comme "algorithm", vector, stream, etc de la STL qui n'indique rien sur le placement/dépendance logique du code dans le projet.
(On utilise des <> pour ce type d'include)

[Médinoc]

Alors, hormis pour la programmation Win32 qui est un peu spéciale de ce côté-là, la règle de base c'est que chaque fichier d'en-tête doit être auto-suffisant, donc il doit inclure tous ceux dont il dépend.

C'est-à-dire, tout ceux dont il utilise des types, ou tout ce qui est utilisé par le code de fonctions inline, etc. (sauf dans le cas où une déclaration anticipée suffit).

Prenons un exemple:

Code C++ :

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

1
2
3
4
5
6
7
8
9
10
11
//Toto.hpp
#pragma once
 
#include "Tata.hpp" //Inclusion
class Titi; //Déclaration anticipée
 
//Cette déclaration utilise le type Tata, et vu que c'est par valeur, on ne peut pas utiliser une déclaration anticipée
void UneFonction(Tata monObjet);
 
//Ici le type Titi est pris par référence, et une déclaration anticipée suffit
void UneAutreFonction(Titi& monObjet);

Il peut alors être directement utilisé dans un code qui en a besoin, sans avoir à inclure un autre fichier d'en-tête avant.
Note par contre, que le code appelant aura quand même besoin d'un #include "Titi.hpp" pour appeler UneAutreFonction().

[KonTiKI]

Merci à tous pour vos réponses.

Je ne m'attendais pas à des réponses aussi "arborescentes" (cf l'arbre d'inclusion).

- Pour les déclarations anticipées, je n'ai pas encore vue cela, je vais devoir étudier ce point.
- Pour les include guards, pas de problème j'ai compris et j'en mets dans mes fichiers. Peut-on malgré cela se retrouver avec une inclusion multiple ?

L'ordre des includes est aussi très important.

Donc en prenant un exemple :

Code :

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

1
2
3
4
 
#include <QtCharts>
#include "maClasse.h"
#include <iostream>

Et le plus simple, et de loin, pour qu'il reste maintenable, c'est de mettre les includes au début du fichier.

Du fichier d'en-tête je suppose.

Mais prenons un cas pratique qui est à l'origine de cette question. J'utilise une fonction, par exemple std::cout de la bibliothèque <iostream> dans mon code source. C'est une fonction interne au fichier .cpp et aucun prototype de méthode n'a besoin de cette fonction. Je mets quand même la directive #include <iostream> dans mon fichier d'en-tête, pas dans le .cpp ?
De ce fait, dans mes fichiers .cpp je n'ai que les #include "fichier.h" ?


Merci pour cette précision complémentaire.

[Bousk]

L'include ne fait que remplacer la ligne par le contenu du fichier.
Si cout n'est pas utilisé dans le header, pourquoi l'inclure dans le header ?
Plus le header est léger, plus la compilation est rapide.

[KonTiKI]

Merci Bousk.

Ca répond à mon problème et surtout, ça valide mon raisonnement.

[bacelar]

Du fichier d'en-tête je suppose.

Le raisonnement est le même pour les fichiers .h et .cpp.

Il ne devrait pas avoir d'include "domestiques" dans le .h car cela ne sert que pour l'implémentation des fonctionnalités, donc rien à faire dans le .h.
Si c'est pour des fonctions inline, c'est qu'elles sont vraisemblablement trop complexes pour être efficacement inline.

Pour reprendre la réponse de @Bousk, on n'inclus que ce qui est nécessaire au fichier, le .h ou le .cpp, donc pas d'include de trucs nécessaire au .cpp dans le .h. C'est au .cpp de se démerder seuls.

Privilégiés les déclarations anticipées et le fait de rendre votre code le plus réutilisable donc réduire le plus possible les includes de .h => moins de dépendance => code plus souple à la réutilisation.

[foetus]

Peut-on malgré cela se retrouver avec une inclusion multiple ?

C'est l'étape d'après , les unités de compilation et le mot clef extern/ static (<- mais en partie)

[KonTiKI]

Sujet particulièrement intéressant avec, comme d'habitude, des réponses d'un haut niveau. Débutant s'accrocher.

Encore une journée de progrès aujourd'hui, merci à tous.

PS : pour l'étape d'après, je vais attendre d'avoir ingurgité celle là, car il m'en reste à avaler.