Discussion :

[LittleWhite]

Bonjour,

Je me suis peut être tromper de catégorie. Premièrement ma question marche aussi pour le C++ mais c'est possible en C.
De plus, je voudrais lancé une sorte de catégorie, qui s'appellerait les codes review. Certes cela pourrait être mis dans "Langage en général" ou "conception" donc si je me suis trompé, vous pouvez déplacé mon sujet ( et acceptez mes excuses ).
Le principe des codes review, serait juste des sujets pour regarder les codes des autres, les techniques employé pour résoudre un problème, des sujets, ou l'on donnerait des conseils ( et demanderai ) sur la clarté du code ( la beauté, j'oserai dire ). Enfin ce serai des sujets, pour progresser sur des points sur lesquelles on ne peut vraiment posé de question précise ( genre comment faire ci, ou alors pourquoi ça marche pas ).
Bref, j'imagine que c'est pas trop possible de faire une catégorie spécialisé pour les codes review, car en même temps ça pourrait être sur n'importe quel langage.
Bref, vous pouvez aussi dire ce que vous en pensez ici ... du coup j'ai une sorte de double sujet :s

La vrai question de ce code review, c'est, on nous conseille de ne pas inclure d'entêtes, dans nos entêtes. Je n'ai rien contre, et cela me semble très logique.
Seul problème, c'est lorsque l'on utilise des bibliothèque qui déclare leurs propres structures/types.
Pour les structures on peut faire une "prédéclaration" ( pardon je ne suis pas sur du terme exacte ) en tête de notre fichier (.h):

Code :

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

1
2
 
struct structure_déclaré_dans_la_bibliothèque;

Et dans le .c il n'y a plus qu'a faire l'inclusion de l'entête de la bibliothèque.

Cette méthode pose deux petits problèmes:
Premièrement, ça veut dire que seul des pointeurs sur cette structure pourront être utilisé plus tard dans le fichier .h, sinon il faut inclure le fichier de la bibliothèque.
Deuxièmement, nous ne pouvons faire ça pour les types (genre la SDL avec les UInt8 ...)

Et dernier point, il est préférable d'éviter de faire des pointeurs partout, alors que cette méthode nous obligerait à faire plus de pointeur.

Comment réglé ces points, sachant que je veux évité on maximum d'inclure le fichier d'entête de la bibliothèque dans mon .h?

Merci pour votre attention

[gl]

La vrai question de ce code review, c'est, on nous conseille de ne pas inclure d'entêtes, dans nos entêtes. Je n'ai rien contre, et cela me semble très logique.

Qui ça "on" ?

Généralement, on essaie plutôt d'avoir des en-têtes autonomes (i.e. ne nécessitant pas d'inclure précédemment un autre en-tête dans les fichiers sources) et ne déclarant que ce qui est nécessaire.
Sauf cas particulier (par exemple certains compilateurs anciens ayant du mal avec les inclusions récursives), si cela nécessite d'inclure un autre en-tête dans notre fichier d'en-tête, il n'y a pas de raison particulière de ne pas le faire.

[LittleWhite]

Le on, cela ne sert pas à grand chose de le dire, entre autre un prof de developpement de JV.
C'est surtout dans le cas si on veut faire une boite noire qui permette d'utiliser facilement plusieurs bibliothèques différentes, en changeant peu de code.

Mais ce que je veux dire aussi, c'est que c'est pas bien d'avoir une inclusion de l'entête d'une bibliothèques dans le .h de notre propre fichier, car partout où l'on va inclure notre fichier, on aura aussi tout le contenu de l'entête de la bibliothèque ( avec tout son lot de définition ).

Mais peut être aussi que mon problème est plus C++ que C, je commence à avoir un doute.

Sinon, comment faites vous pour avoir vos entêtes autonomes ?

[gl]

C'est surtout dans le cas si on veut faire une boite noire qui permette d'utiliser facilement plusieurs bibliothèques différentes, en changeant peu de code.

Mais ce que je veux dire aussi, c'est que c'est pas bien d'avoir une inclusion de l'entête d'une bibliothèques dans le .h de notre propre fichier, car partout où l'on va inclure notre fichier, on aura aussi tout le contenu de l'entête de la bibliothèque ( avec tout son lot de définition ).

Si la connaissance de l'en-tête de la bibliothèque est nécessaire dans notre en-tête, oui il faut l'inclure (dans le cas contraire, de toute manière, il aurait nécessaire d'inclure cet en-tête préalablement à la notre dans tout fichier source incluant notre en-tête, ce qui est bien pire).
Si notre en-tête n'a pas à en avoir connaissance, l'en-tête de la bibliothèque n'a pas à être inclus dans notre en-tête.

Pour en revenir à la boîte noire dont tu parles, généralement le code utilisateur n'a pas à avoir connaissance de la bibliothèque sous-jacente et notre propre en-tête n'a aucune raison de s'en servir, elle ne sera donc pas incluse dans notre en-tête.

Le cas un peu plus "litigieux" est celui où seule une déclaration anticipée (ce que tu as appelé predéclaration) d'une structure est nécessaire à notre en-tête. Dans ce cas, il peut être effectivement envisageable de ne mettre effectivement que cette déclaration anticipée dans notre propre en-tête (à moins que la bibliothèque en question n'est prévue justement un en-tête spécifique ne contenant que les déclarations anticipées.

Sinon, comment faites vous pour avoir vos entêtes autonomes ?

En appliquant les explications données ci-dessus.

[LittleWhite]

Mais, on peut pas faire de déclaration anticipé pour les variables, n'est ce pas?

Je vais prendre un exemple avec la SDL.
J'ai une fonction de la SDL qui va prendre les types déclaré par la SDL. Je veux faire une sorte de surcouche de cette fonction, donc dans mon .h je vais avoir un prototype très proche de celui de la fonction de la SDL.
Dans le .c, bien sur la fonction qui je crée appelle la fonction de la SDL. Donc dans le .c j'inclue le fichier d'entête de la SDL; pas de problème la dessus.

Mais comme la SDL est multiplateforme, elle redéfini ces types. Donc ma fonction devra utilisé ces types. Le problème c'est que du coup, je dois inclure le fichier d'entête dans mon .h. Et du coup dans tout le reste du programme, je verrai aussi les trucs de la SDL.

Mais si je fais plus comme vous dites, et je me contente que des types de bases, il se peut que j'ai des problèmes avec les différentes plateforme que j'utilise, car les types peuvent avoir une représentation différente.
Donc dans ce cas, que dois je faire?

[gl]

Mais comme la SDL est multiplateforme, elle redéfini ces types. Donc ma fonction devra utilisé ces types. Le problème c'est que du coup, je dois inclure le fichier d'entête dans mon .h. Et du coup dans tout le reste du programme, je verrai aussi les trucs de la SDL.

Je ne connais pas la SDL, mais les définitions des types ne seraient-elles pas dans un fichier d'en-tête ne contenant que ces déclarations ? Dans ce cas, inclure ce fichier n'importe pas toute la SDL mais seulement les types.