Discussion :

[Aleph69]

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?

[Bousk]

Salut,

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

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

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

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>
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.
Une fonction amie de plusieurs classes, c'est peut-être plutôt un problème de conception.

[Aleph69]

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.

[jblecanard]

Hello

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.

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.

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 .

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.

[Bousk]

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é ?
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.

[ternel]

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>

[Aleph69]

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.