Discussion :

[Pyramidev]

Soit un fichier "Foo.cpp" qui utilise la classe truc::Log et un autre fichier "Bar.cpp" qui utilise une autre classe chose::Log.

Admettons que "Foo.cpp" et "Bar.cpp" fassent tous les deux un #include "Log.h", mais chacun visant un fichier différent.
Le jour où un projet contiendra à la fois "Foo.cpp" et "Bar.cpp", on sera dans de beaux draps.
Heureusement, ce problème peut être évité en amont.

Solution 1 : L'inclusion prend en compte le dossier parent.

Une première solution serait que toutes les classes de l'espace de nom truc soient déclarées dans des fichiers d'entête qui sont dans un dossier "Truc". Même logique avec chose.
Alors, "Foo.cpp" pourra faire un #include "Truc/Log.h" et "Bar.cpp" pourra faire un #include "Chose/Log.h".
C'est la stratégie utilisée par Boost : tout est dans l'espace de nom boost et toutes les inclusions sont de la forme #include <boost/qqch> ou #include "boost/qqch".

Solution 2 : Le nom du fichier inclut l'espace de nom.

Une deuxième solution serait que le nom du fichier inclut l'espace de nom. Par exemple, on pourrait choisir le format "EspaceDeNom.NomDeClasse.h".
Ainsi, "Foo.cpp" pourra faire un #include "Truc.Log.h" et "Bar.cpp" pourra faire un #include "Chose.Log.h".

Quelle solution choisir ?

L'inconvénient de la première solution, c'est qu'un développeur pas assez sensibilisé aux collisions de noms pourrait écrire un peu partout des #include "Log.h" sans mentionner explicitement le dossier parent. (Il ajouterait alors ledit dossier à la liste des dossiers d'inclusion du projet pour que ça compile.)

Mais est-ce que la première solution a des avantages que n'a pas la deuxième ?

[JolyLoic]

La seconde:
- Mélange architecture physique (fichiers) et logique (namespace)
- Ne gère pas un .h qui perlerait de plusieurs namespaces (conséquence du point précédent)
- Oblige à être explicite même quand on est en train d'inclure dans la même bibliothèque
- Fait que dans le répertoire Chose, on aura tout un tas de fichiers commençant par Chose.xxx, ce qui rend la navigation dans le répertoire (ou la complétion en ligne de commande) plus lourde

Je préfère largement la solution 1, avec les règles suivantes :
- Dans la configuration d'un projet, on a de droit de mettre en include path uniquement une "racine", soit celle de notre code, soit celle d'une bibliothèque externe, mais pas un sous répertoire.
- Dans une directive include, pas le droit de mettre des .. (j'hésite à les autoriser dans le cas uniquement du projet de tests unitaires qui voudrait ainsi accéder au code qu'il teste).

Celui qui ne respecte pas ça, tant pis pour lui

[Pyramidev]

La seconde:
[...]
- Oblige à être explicite même quand on est en train d'inclure dans la même bibliothèque

A ce propos, avec la première solution, avec les préprocesseurs les flux fréquents, a-t-on la garantie que #include "qqch" cherchera en priorité dans le même dossier ?
Par exemple, dans un fichier "Truc/Exemple.cpp", si on fait #include "Log.h", a-t-on la garantie que "Truc/Log.h" sera prioritaire par rapport à "Chose/Log.h" ?

Le standard C++ (16.2) ne tranche pas et se contente de dire que la recherche est définie par l'implémentation. (J'ai regardé dans le draft de C++14, section 16.2.)

[Bktero]

Après plusieurs années à faire de l'applicatif en Java et des drivers en C, je reviens sur des projets uniquement C/C++. Partant de rien, j'ai pris comme parti sur mon projet d'utiliser des #includes avec le chemin complet, sauf pour les en-tête qui sont dans le même dossier (par exemple, foo.cpp inclut foo.hpp qui est dans le même dossier).

A noter que j'avais commencé avec un include path plus complet et donc des #includes sans arborescence complet et que j'ai rapidement retravaillé mon (encore petit) projet pour utiliser des chemins complets.

Plusieurs raisons m'ont motivé :
- L'include path est très simple, il contient uniquement le dossier source racine.
- Je suis explicite sur ce que je veux inclure.
- On évite les collisions de noms et on a des en-têtes qui sont nommées simplement. C'est l’arborescence pour les trouver qui permet de les cataloguer.
- Je retrouve plus facilement le fichier d'en-tête si je souhaite le changer (même si avec un éditeur moderne on peut "suivre le lien").

Je ne sépare pas les sources et les en-têtes. Je fais donc des dossiers et sous-dossiers thématiques (j'ai voté autre car je n'ai pas que le dossier parent, des fois il y en a plusieurs, et c'est indépendant des namespaces (que je n'utilise pas encore...)).

En gros, je fais des packages à la Java ^^

[ternel]

Une bonne source d'inspiration, sur ce sujet, c'est boost.
Chaque module propose un include globale dans la racine boost, et d'autres dans des sous-dossiers propres.
Par exemple, pour le module Boost.Optional, on a:

• boost/none.hpp (et none_t.hpp)
• boost/optional.hpp
• boost/optional/optional.hpp
• boost/optional/optional_fwd.hpp
• boost/optional/bad_optional_access.hpp
• boost/optional/optional_io.hpp

le premier est une sous-bibliothèque minuscule, sans aucune dépendence.
le second boost/optional.hpp permet une inclusion complete légère à écrire, il se contente d'inclure boost/optional/optional.hpp

Le seul include path requis est celui ou se trouve le dossier boost (le dossier include de l'installation)

[oodini]

J'utilise la solution 1.

J'ajouterai que lorsque je me repose sur une directive de compilation d'inclusion d'un répertoire, j'utilise les chevrons.
Si j'inclus par rapport au fichier courant, j'utilise des guillemets. Sans jamais remonter dans les répertoires.

[Bktero]

Les chevrons devraient être réservés pour les en-têtes systèmes au passage http://stackoverflow.com/questions/2...clude-filename

[oodini]

Je sais, et c'est pour cela que je précisais mon utilisation.

Tel que c'est décrit dans la norme (paragraphe 16.2 de N3337) et dans la doc de GCC 4.9.2 (que j'utilise), tout cela ne semble être qu'une affaire de conventions.
Le seul comportement qui ne relève pas d'une convention est que si une en-tête n'est pas trouvée par les chemins définis pour "", alors elle est recherchée avec les chemins définis pour <>.

Par ailleurs, je n'ai que très rarement vu dans des projets l'utilisation de l'option -iquote, et toujours celle de -I.