Organisation des fichiers

Bonjour,

je me pose des questions sur la manière optimale d'organiser mes fichiers.

Je suis depuis un moment le schéma suivant pour une classe Foo :
- Foo_fwd.hpp contient la déclaration anticipée de Foo;
- Foo.hpp contient la déclaration de la classe Foo;
- Foo_inline.hpp contient les fonctions membres inline;
- Foo_template contient les fonctions membres template;
- Foo.cpp contient l'impélmentation qui n'est ni template ni inline;
- Foo_friend.hpp contient les déclarations des fonctions amies.

J'ai notamment un problème avec les fonctions amies.
Je ne sais jamais vraiment où les ranger quand elles sont amies de plusieurs classes.

Comment procédez-vous?

Salut,

t'es adepte de l'over-engeenering et de la prise de tête non ?

Citation:

---

Foo_fwd.hpp contient la déclaration anticipée de Foo;

---

Tu veux dire que tu as un fichier pour écrire class Foo; ? :weird:

Après tout, pourquoi faire simple quand on peut faire compliqué !

Foo.hpp
Foo.cpp
Foo.tpl (inl, ...) pour l'implémentation template - quand c'est pas juste à la fin du hpp, ou dans son corps

Quelqu'un a besoin d'une simple forward declaration ? Il écrit class Foo;. Au passage, ça sera plus simple, moins chiant et plus rapide que #include <Super/Path/To/Foo_fwd.hpp> :calim2:
Les fonctions inline ? Ben dans le hpp elles sont très bien.
Les déclaration d'amitié ? Elles sont dans le corps de la class. :weird:
Une fonction amie de plusieurs classes, c'est peut-être plutôt un problème de conception.

Bonsoir Bousk,

merci pour ta réponse.

Je ne partage pas ton point de vue concernant les déclarations anticipées.
Avec ton approche, tu ne factorises pas ton code.
Si tu changes le nom de ta classe, si tu ajoutes un paramètre template, etc, tu devras répercuter ta modification partout.
Par ailleurs, je ne vois pas en quoi réécrire explicitement tes déclarations anticipées est plus simple ou plus rapide à écrire, surtout si tu manipules des classes plus avancées possédant plusieurs paramètres template.

Pour le fait de réunir les fonctions inline et template dans un seul et unique fichier d'implémentation foo_impl.hpp, c'est effectivement une question que je me pose.
Le fait de séparer les fonctions inline me paraît intéressant quand on fait beaucoup d'optimisation.
On voit plus facilement où il n'y a pas d'expansion de code.
Mais c'est peut-être inutilement compliqué, j'en conviens.

Enfin, avoir une fonction amie de plusieurs classes ne me paraît pas du tout être un problème de conception.
C'est par exemple le cas typique quand tu as une classe Vecteur, une classe Matrice, et une fonction amie de ces deux classes calculant le produit entre une matrice et un vecteur.

Hello

Citation:

---

Envoyé par Aleph69

Si tu changes le nom de ta classe, si tu ajoutes un paramètre template, etc, tu devras répercuter ta modification partout.

---

Tu te contredis toi même, avec ta méthode, si tu changes le nom de ta classe, il faut aussi renommer tous les fichiers et changer tous les includes correspondants, ce qui revient au même. Et de toute façon, il faudra changer les endroits ou le nom de cette classe est utilisé : ton header n'y change rien, tu n'économises qu'une seule ligne de changement.

Citation:

---

Envoyé par Aleph69

surtout si tu manipules des classes plus avancées possédant plusieurs paramètres template..

---

D'accord sur ce point, mais dans le cas d'une classe template complexe qui le justifie (je l'ai déjà fait aussi). Dans la pratique, ça ne concerne qu'une minorité de classes, ce n'est pas une bonne idée d'en faire une pratique systématique.

Citation:

---

Envoyé par Aleph69

Pour le fait de réunir les fonctions inline et template dans un seul et unique fichier d'implémentation foo_impl.hpp, c'est effectivement une question que je me pose.
Le fait de séparer les fonctions inline me paraît intéressant quand on fait beaucoup d'optimisation.
On voit plus facilement où il n'y a pas d'expansion de code.
Mais c'est peut-être inutilement compliqué, j'en conviens.

---

Franchement, ça ça ne peut se justifier que dans un seul cas : si tu dois avoir plusieurs implémentations différentes en fonctions de la plateforme, et que tu règles ta toolchain pour que ce soit la bonne implémentation qui soit choisie à la compilation. En dehors de ça, ça ne fait que rajouter du code et allonger le temps de compilation, en échange de rien. La séparation n'est que cosmétique, puisque tu dois quand même inclure ton *_impl dans le header principal :aie:.

Pour les friends, sans rentrer dans le débat d'avoir plusieurs friends ou pas, je vois vraiment pas ce que ça apporte à part rendre la gestion des headers plus compliquée pour les utilisateur de la classe. Je vois ça dans du code, je le vire direct.

Je suis d'accord avec Bousk, tu te compliques la vie. Il faut faire au plus simple et ne rajouter de la complexité que si elle apporte quelque chose. L'éclatement en plein de fichiers, je l'ai vécu sur une grosse base de code, c'est un véritable enfer.

Citation:

---

Envoyé par Aleph69

Avec ton approche, tu ne factorises pas ton code.
Si tu changes le nom de ta classe, si tu ajoutes un paramètre template, etc, tu devras répercuter ta modification partout.

---

Euh... gné ? :calim2:
Si je change le nom d'une classe, je vais devoir modifier tous les endroits où je déclare cette classe. Je vois pas ce qu'il y a de choquant ni ce que ta "méthode" permet d'éviter ou améliorer. :weird:

bah, si ton fichier qui prédéclare la classe Foo s'appelle foo_fwd.hpp et que tu renommes ta classe en Bidule, l'utilisateur s'attend par cohérence avec les autres classes à avoir bidule_fwd.hpp.

Du coup, il faut renommer le fichier et donc modifier quand même les programmes.

La seule raison d'avoir un tel fichier, c'est quand tu prédéclares plusieurs classes ensembles.
C'est ce que fait <iosfwd>.
Tu remarqueras qu'il n'y a pas de <vector_fwd>, <map_fwd> ou <string_fwd>

Bonsoir,

effectivement, je comprends tout à fait que l'argument du changement de nom de classe n'est pas recevable.
En revanche, modifier la déclaration d'une classe en ajoutant des paramètres template nécessite bien de répercuter ce changement partout où cette classe fait l'objet d'une déclaration anticipée.
En la déclarant dans un fichier d'en-tête, je n'ai qu'une seule modification à produire.
C'est également très intéressant quand on veut éviter d'écrire des déclarations anticipées de classes template un peu complexes; et ce cas est loin d'être rare, en tous cas dans mon domaine (calcul scientifique).

C'est vrai : la STL n'adopte cette approche que pour <iosfwd>.
Mais, il y a un historique qui va avec la STL et certains aspects la concernant ne sont pas des modèles de conception à suivre (cf string).
L'approche dont je vous parle est par exemple adoptée dans Effective C++.
Je ne me souviens plus des arguments de Meyer mais je vais regarder.

J'entends tous vos arguments mais je n'arrive pas être convaincu : je trouve l'approche par fichier plus simple et meilleure en terme de factorisation de code.
Pour les fonctions inline, je suis d'accord que ça complique les choses et je vais sûrement abandonner cette pratique.
En ce qui concerne les fonctions amies, je suis toujours preneur d'un avis sur le lieu où les définir quand elles sont amies d'au moins deux fonctions.
Si c'est un problème de conception, je veux bien qu'on m'explique comment écrire un produit entre une matrice et un vecteur.

Citation:

---

Envoyé par Aleph69

je trouve l'approche par fichier plus simple et meilleure en terme de factorisation de code.

---

Juste une petite remarque sémantique. « Factoriser » = regrouper ensemble les facteurs. Séparer en plein de fichiers me semble, sémantiquement parlant, à l’opposé.

Après, les goûts et les couleurs… Pose-toi quand même la question de la pertinence d’avoir 5 fichiers par classe, et si le rapport gain / coût est vraiment valable. Personnellement, je vois bien le coût, je ne vois pas le gain pour l’instant.

Citation:

---

Envoyé par Aleph69

En ce qui concerne les fonctions amies, je suis toujours preneur d'un avis sur le lieu où les définir quand elles sont amies d'au moins deux fonctions.
Si c'est un problème de conception, je veux bien qu'on m'explique comment écrire un produit entre une matrice et un vecteur.

---

Déjà, je ne suis pas un partisan du 1 classe == 1 header. Les fonctions amies vont, en règle générale, dans le même header que celui de la classe. Et si jamais une de tes fonctions doit être amie de deux classes, tu choisis comment la convention ? Moi c'est simple, je met tout le monde dans le même header et basta.

Salut,

Deuxième règle de développement SOLID : l'OCP (Open Close Principle) !!!! Ton code doit être ouvert aux évolutions mais fermé au modifications. Ou, si tu préfères, une fois que ton code a été testé, il ne faut plus y toucher à moins que son utilisation n'ait mis un problème en évidence (un "bug" ;) ).

Si tu veux renommer ta classe, tu dois avoir de très bonnes raisons pour le faire, et, de toutes manières, la déclaration anticipée ne sera pas (et de très loin) le seul endroit où il faudra modifier le nom : une déclaration anticipée permet juste au compilateur de savoir qu'il existe un type dont le nom est indiqué, afin qu'il puisse décider d'accepter la signature d'une fonction prenant le type en question comme paramètre sous la forme d'une référence ou d'un pointeur ou renvoyant une référence (ou un pointeur) sur le type en question.

Pour chaque déclaration anticipée, tu dois donc t'attendre à devoir également modifier au minimum la signature d'une fonction (quand ce n'est pas de beaucoup plus), non seulement, au niveau de la déclaration de la fonction (de la définition de la classe dans laquelle la fonction apparait), mais aussi au niveau de l'implémentation de la fonction... et donc, également, au niveau des fonctions appelantes.

Placer une déclaration anticipée unique ne t'apportera absolument rien (car, encore une fois, la déclaration anticipée sera ton moindre problème).

Pour le reste : on ne décide que très rarement d'ajouter un paramètre template à une classe ou à une fonction. Si l'on prend ce genre de décision, c'est dans le cadre d'une évolution qu'il faut apporter et non dans celui d'une simple modification. Mais le fait d'apporter une évolution au code ne justifie absolument pas que l'on décide de revenir sur des objectifs précédant dores et déjà validé.

Si tu as développé une classe template qui ne prenait qu'un seul paramètre template, c'est très certainement parce que cet unique paramètre template était correct et suffisant dans l'état des connaissances que tu en avais lors du développement de la classe. Les évolutions qui arrivent par la suite vont sans doute apporter leur lot de complexité supplémentaire, mais, le besoin d'origine qui ne nécessitait qu'un seul paramètre template n'en deviendra pas caduque pour la cause.

Tu as donc deux solutions : soit tu modifies la classe existante afin de rajouter un paramètre template, mais tu dois alors veiller à rendre ce paramètre supplémentaire optionnel, pour ne pas te trouver face à l'obligation de modifier tout ton code existant, soit tu dois créer -- purement et simplement -- une nouvelle classe correspondant au besoin de ton évolution. Quitte à ce qu'elle s'appuie d'une manière ou d'une autre sur la classe existante ;)

L'un dans l'autre, la création d'une nouvelle classe destinée à prendre en charge une évolution devrait toujours être préférée à la solution qui consiste à rajouter un paramètre optionnel.

Enfin, il faut savoir que la directive préprocesseur #include est loin d'être gratuite en termes de temps de compilation. La règle générale est donc simple : il faut essayer d'inclure le stricte minimum dans chaque fichier. En arriver à avoir trois directive d'inclusion (et donc autant de garde anti inclusion multiple) pour le seul plaisir d'avoir un fichier par "type de fonction" spécifique, c'est du pur masochisme :)

Bonjour,

d'accord, je comprends bien vos arguments.
Je n'ai réellement aucune idée de ce que coûte l'inclusion d'un fichier d'en-tête.
Est-ce que cette information est connue?

Par ailleurs, dans l'hypothèse où l'on est partisan d'écrire un fichier par classe, comment fait-on pour traiter le cas des fonctions amies de plusieurs classes?