Comme Dragonic : Le problème est le suivant : j'ai un très gros code à maintenir qui contient plusieurs librairies externe ainsi que du code interne.
Chaque librairies contient ses propres includes pour pouvoir les compiler.
Je possède aussi mes includes pour mon projet.
La conséquence de cela est que je me retrouve avec un très grand nombre d'include au niveau du préprocesseur. Et parfois suivant les noms des fichiers on peut penser qu'au niveau de la phase de link on ne prenne pas le bon fichier, de plus de confondre les fichiers entre les librairies, lors d'une mise à jour d'une dernière cela complique encore plus les choses en cas d'erreur.
Quel est donc votre méthode pour limiter ces includes -I afin de compiler de gros projets et afin d'éviter les erreurs de ce type ?
Il y a aussi une méthode pour éviter les includes lorsqu' il y a des pointeurs, la déclaration anticipée ( que j'utilise souvent en C++ ). Mais cela peut aussi marcher en C. Quand dans un fichier d' en-tête on passe un type par adresse ou un pointeur par valeur on est pas obligé d' inclure l' en-tête qui defini ce type (en C il s' agit surtout d'une structure ).
Personnellement, j'inclus et c'est tout. Si ça prend 25 inclusions alors ainsi soit-il. Mon choix est orienté par une volonté de transparence, j'aime me relire sans avoir à me déchiffrer.
J'ai appris très rapidement qu'être clair et explicite en tout temps est bien plus précieux qu'une "optimisation" opaque... Si vraiment ça optimise quelque chose.
Parfois, les quelques secondes que tu vas gagner maintenant en voulant "planquer" un truc pour rendre les choses faciles, te coûteront plusieurs minutes de retro-engineering pour te relire alors que ton "astuce" te sera sortie de la tête. Disons dans 10 ans.
Si j'ai besoin d'exporter un fichier, les dépendances sont signifiées dans ce même fichier, pas besoin de se perdre en recherches de références croisées en références croisées.
mouais mais bon, ce n'est pas qu'une histoire d'include … c'est une gestion de projets avec des bibliothèques externes qui sont apparemment compilées exprès pour le projet (ce qui en soit n'est pas une mauvaise chose). Et là il faut absolument avoir quelque chose qui gère le projet globalement sinon on s'arrache les cheveux.
Comme Dragonic : Le problème est le suivant : j'ai un très gros code à maintenir qui contient plusieurs librairies externe ainsi que du code interne.
Chaque librairies contient ses propres includes pour pouvoir les compiler.
Je possède aussi mes includes pour mon projet.
La conséquence de cela est que je me retrouve avec un très grand nombre d'include au niveau du préprocesseur. Et parfois suivant les noms des fichiers on peut penser qu'au niveau de la phase de link on ne prenne pas le bon fichier, de plus de confondre les fichiers entre les librairies, lors d'une mise à jour d'une dernière cela complique encore plus les choses en cas d'erreur.
Quel est donc votre méthode pour limiter ces includes -I afin de compiler de gros projets et afin d'éviter les erreurs de ce type ?
Bien cordialement.
Kasi
- compartimenter
- limiter l'interface publique à l'essentiel
- proprement définir les dépendances de chaque "target" de manière fine (ni plus ni moins)
- pas de nom générique pour les headers publiques, ou alors les isoler dans un répertoire dont le nom n'est pas générique
- préfixer ses symboles en C pour éviter les collisions
- éviter de faire baver les dépendances externes dans les headers publiques
Problème d'include : Comment faites vous?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Mon site web de jeux SDL2 entre autres : https://www.ant01.fr
Bonhomme !! | Jeu de plateforme : Prototype.