Ton exemple des fichiers standard, c'est parce qu'ils ont chacun besoin des autres et qu'ils sont conçus pour être inclus par d'autres.

Moi je n'inclus jamais rien dans mes .h : chaque fichier .c inclut les .h dont il a besoin, bibliothèque standard et .h du programme. Résultat : tout marche très bien, jamais de problèmes d'inclousions n'importe comment.

Je ne dis pas que c'est pas une solution viable ton truc, mais je dis qu'on n'est pas obligé et je ne le fais pas.

Les .h standards font ce qu'ils veulent, ils n'ont même pas besoin d'exister, ça peut être magique que quand tu marques #include <stdlib.h> tu aies accès aux fonctions.

Tu trouves ça ptet pas pratique d'inclure à chaque fois dans le .c _tous_ les headers nécessaires. Si tu veux un argument d'autorité :
"Simple rule: include files should never include include files."
--- Rob Pike

Pour ceux qui veulent une explication de pourquoi je préfère faire comme je fais :

1. La première raison est que si on inclut tous les fichiers headers en début de fichier C, juste en regardant là, on peut connaître _tous_ les symboles réservés dans ce fichier C et on pourra tranquillement définir ses fonctions statiques sans aucun risque de conflit stupide de nom. Parce que c'est beau la réutilisation du code, mais si tous les .h s'incluent entre eux, tu te retrouvent à la fin avec des symboles définis dans ton .c dont tu n'as _aucune_ idée d'où ils sortent. (Ca m'est arrivé en portant un code Linux sous Windows, un de mes nom était réservé par windows.h qui comme un gros sale inclut plein de fichiers sans te prévenir...) Avec ma méthode, pour peu que les headers soient bien faits et aient une certaine stabilité, tu n'auras presque jamais ce genre de conflit obscure. En général, si tu "versionnises" tes headers, tu auras des choses du genre :
#if MYLIB_VER >= XXX
/* nouvelles déclarations */
#endif
Et vu que tu connais tous les headers incluent tu n'auras aucun conflit de nom si tu ne cherches pas les coups en déclarant la macro toi-même...

2. Faire ce genre d'inclusion met beaucoup de poids sur le parser, parce que même si tu ne l'évalue pas, il faut bien que les lexer le lise et après, vive le temps de compilation si tu inclues 5 fois le même fichier de 1000 lignes (avec des fonctions inlines, c'est tout à fait plausible) ça te fait déjà 5k lignes en plus... <_< Recommence avec tous les fichiers avec lesquels tu fais ta protection et tu vois le truc.

M'écoutera qui voudra mais je vous donne une *vraie* solution, faut pas croire que c'est parce que je fais moins sophistiqué que c'est moins bien.

1 - Dans certain cas, on na pa du tout el choix, on est obliger. Notament avec les composants qt. Metenant, sa reste rare.
J'ai remarquer que tu préfèrais inclure tout les .h dnas le .c, moi je préfère inclure tout ems .h dans le .h qui corespond au .cpp l'utilisant. Chacun ses conventions.

2 - J'ai remarquer, c'est pour sa que dans les demos de Qt, ils mêttent un class name{}; et n'inclut le QtGUI que dnas le .cpp
Comme sa, a chaque foi que tu recompile ton projet(Mais que tu ne modifi pas ton composant) tu gagne enormement de temp. Pour info, quand j'inclut QtGui dans mon .h, je me tape 5seconde suplémentaire a la compilation. Bon, c'est pas la mort, mais quand tu compile juste pour avoir remplacer std::cout << "tst"; par std::cout << 3tst:" << var;, sa agace un peut.

En fait, lorsque tu dis que l'on n'a pas le choix ; c'est vrai, mais en général, les libs bien faites ont des specs qui définissent clairement ce que chaque header déclare, après, comment il le déclare, ce n'est pas ton problème et les gars qui font les libs ne vont pas s'amuser à déclarer derrière ton dos en incluant n'importe comment. Je veux dire par là qu'au final, c'est pas tellement ton problème ce que font les libs.