Discussion :

[kronoss]

bonjour,

je me demandais quel était l'avantage d'avoir un fichier cpp par header alors qu'on peut tout mettre dans le header, ce qui impliquerait:

- moins de fichiers
- ne pas devoir modifier le header à chaque modification de méthode ou variable dans le cpp
- compilation plus rapide
- moins de sources d'erreurs

je suppose que si il y a les 2 c'est qu'il y a une bonne raison non ?

merci de m'éclairer

[LittleWhite]

Bonjour,

Oui, il y a une bonne raison.

Tout mettre dans le header, veut dire que l'on se retrouve avec les fonctions inclut partout dans le code source ( directive du préprocesseur #include ). Donc au final, code qui compilera lentement, et qui sera plus gros ( taille executable ).

De plus, ce sera un peu foutoir. Par exemple de base dans mon .h j'ai défini 10 nouvelles structures, si en plus je rajoute mon cpp en dessous , ça va devenir foutoir.

Moins de sources d'erreurs ... je suis pas sur ... ou alors j'ai assez d'expérience pour eviter de base les erreurs, ou les reconnaitre rapidement.

Voilà un début de réponse ( je pense )

[JolyLoic]

L'idée de base est de séparer l'interface de l'implémentation. Et le principal problème que je vois aux headers en C++ est qu'on est souvent obligé de mettre dedans des détails d'implémentations qui n'ont rien à y faire (à moins d'utiliser des techniques comme le pimpl qui ont un coût au runtime). Espérons que les modules arriveront en C++ de mon vivant, et que je pourrai alors voir une meilleure solution.

Tu peux si tu le veux mettre beaucoup de chose dans un .h, mais tu perds alors ses avantages qui sont :

- Compilation plus rapide : Dans un modèle de compilation séparée, mettre trop de code dans les .h aurait pour effet de compiler ce code dans chaque unité de compilation, ce qui aurait un coût (voir par exemple le bench de J.-M. Bourguet sur export, qui montre cet effet dans un cas de templates qui obligent à mettre du code dans les .h)

- Recompilation plus rapide : Souvent une modification ne touche qu'un .cpp, pas son .h, car l'interface a tendance à être plus stable que l'implémentation. Du coup, on n'a besoin de ne recompiler que ce cpp, contre tout le code utilisant le .h si on avait mis trop de choses dedans.

- Clarté du code, un client n'a pas à voir l'implémentation, seulement l'interface. Avec une séparation de code, on lui montre une vue claire et synthétique de celle-ci (cette raison me fait aussi me méfier des systèmes d'annotation des .h pour génération de doc semi automatique)

- Possibilité d'appliquer des restrictions d'accès différente à l'interface qu'à l'implémentation. Je n'ai personnellement jamais vu, mais j'ai entendu parler de cette pratique dans des grosses organisations.

[kronoss]

Perso je ne trouve pas ça pratique, d'ailleurs (corrigez moi si je me trompe) dans les autres langages tout est dans un même fichier (pour une même classe), et ils s'en sortent très bien... enfin bref

merci pour ces réponses.

[Chatanga]

Dans des langages tels le C, C++ et l'Objective-C, on distingue la déclaration d'un symbole de sa définition. C'est indispensable car la seule manière, dans une unité de compilation, de référencer quelque chose "d'extérieur" est l'utilisation de la directive de précompilation include (et import) qui inclut physiquement une dépendance. Il est donc obligatoire, par exemple, de séparer la déclaration d'une fonction de sa définition si on veut inclure l'une et pas l'autre.

Dans d'autres langages, tels le Java, le problème ne se pose pas car l'instruction y import sert uniquement à récupérer les déclarations de symboles à partir de classes (et non de sources) Java. La séparation entre déclaration et définition s'oppère ainsi naturellement.

Alors, les premiers langages cités sont-ils moins évolués ? Oui Sans doute, mais il faut aussi comprendre qu'ils permettent aussi d'autres choses via cette inclusion de définition de symbole innaccessibles à des langages comme Java. Toute la méta-programmation en C++ exige ainsi de pouvoir inclure des définitions de classes. On peut aussi penser aux optimisations permises par le fait que le produit d'une compilation en C n'a pas besoin, comparée à Java, de contenir un ensemble de méta-informations jouant le "rôle" d'include. C'est pour cette raison que l'inclusion de bibliothèques C (p. ex. un ".so") n'est pas possible directement (du moins si les informations de débugage ont été retirés).

Pour finir, il faut aussi comprendre que séparer déclaration et définition s'impose parfois à un niveau plus élevé dans un programme, y compris en Java via l'introduction d'interfaces. Il est vrai toutefois qu'il s'agit dans ce cas d'une préoccupation de conception et non d'une contrainte technique.

[JolyLoic]

Perso je ne trouve pas ça pratique, d'ailleurs (corrigez moi si je me trompe) dans les autres langages tout est dans un même fichier (pour une même classe), et ils s'en sortent très bien.

Dans l'autre langage que je connais le mieux (c#), tout est en effet dans un seul fichier, mais je n'estime pas que le langage s'en sort bien :
- Malgrès son temps de compilation intrinsèquement bien plus rapide que le C++, le fait que chaque petite modification d'implémentation oblige à tout recompiler est énervant, et je me retrouve parfois à attendre plus longtemps la recompilation C# que la recompilation C++..
- Les fichiers C# sont souvent plus foutoir, et j'ai du mal en lisant le code à avoir une vue d'ensemble de ce qu'une classe est sensée faire, malgré les astuces les astuces de l'éditeur pour pallier à ce problème (en repliant le code). En C++, et sans éditeur spécifique, j'arrive à lire un .h sans problème.

Là où c'est moins pratique, en C++, c'est que ça demande un apprentissage supplémentaire pour s'en servir. Mais au final, je préfère largement.

[LittleWhite]

(...) le fait que chaque petite modification d'implémentation oblige à tout recompiler est énervant, et je me retrouve parfois à attendre plus longtemps la recompilation C# que la recompilation C++..

Surtout quand le compilateur à une fuite de mémoire ( C# 2008 express édition, avec XNA ( bon j'étais surement encore sur un truc bien spécifique comme par hasard ) )

- Les fichiers C# sont souvent plus foutoir, et j'ai du mal en lisant le code à avoir une vue d'ensemble de ce qu'une classe est sensée faire

Entièrement d'accord ... je n'apprécie pas totalement le C# à cause de ça ( entre autre ).

- Clarté du code, un client n'a pas à voir l'implémentation, seulement l'interface. Avec une séparation de code, on lui montre une vue claire et synthétique de celle-ci (cette raison me fait aussi me méfier des systèmes d'annotation des .h pour génération de doc semi automatique)

Oui mais pas que, je ne l'ai pas vu dit, mais il faut savoir, que si on fait une bibliothèque ( mais qui doit être utilisé pour du développement d'autre chose ) genre SDL2 , et que l'on veut mettre une licence assez restrictives ( genre un truc commercial ), si on fout tout notre code C, dans le .h, comme on fait pour redistribuer la bibliothèque sans dévoilé notre code que l'on fait payé . (Enfin j'espère que vous avez saisi ce que je veux dire.

[Invité]

- Possibilité d'appliquer des restrictions d'accès différente à l'interface qu'à l'implémentation. Je n'ai personnellement jamais vu, mais j'ai entendu parler de cette pratique dans des grosses organisations.

C'est en fait assez courant...

Trois bonnes raisons de faire cela

1- pour cacher une implémentation confidentielle aux développeurs qui l'utilisent (soit qu'ils n'appartiennent pas à la boite, soit qu'ils n'aient pas les accréditations nécessaires)

2- pour empêcher que l'implémentation soit modifiée par erreur (par exemple si la librairie est utilisée par plusieurs projets, on ne veut pas qu'un développeur trop zélé décide de l'améliorer, et risque de déstabiliser les autres)

3- pour garantir la possibilité de faire évoluer l'implémentation sans déstabiliser les programmes utilisateurs : en gros, on refournit une autre librairie compilée, les même headers, et normalement, il suffit de relier tout cela

J'ai vu les trois se faire, même dans de toutes petites boites.

Francois

[Lavock]

J'ai même tendance à faire encore "pire" : je compose une "grosse classe" avec jusqu'à 4 fichier : - Un pre-header (declaration anticipé); un header (déclaration); un post-header (fonction inline + fonction template); et un source.

J'espère grandement pouvoir me débarasser du post-header pour tout mettre dans le source... Malheureusement je ne crois pas que ce soit au programme !

Le seul et unique avantage que j'ajouterai, c'est pour les "référence cyclique", qu'il faut fortement éviter en temps normal...

[camboui]

Je crois qu'on a oublié l'essentiel, et il n'y a pas le choix, la déclaration du code doit être dans un cpp. Sans quoi le linker risque de se plaindre en trouvant plusieurs fois le même code (sauf à n'avoir qu'un seul cpp pour tout le projet).

[Invité]

Je crois qu'on a oublié l'essentiel, et il n'y a pas le choix, la déclaration du code doit être dans un cpp. Sans quoi le linker risque de se plaindre en trouvant plusieurs fois le même code (sauf à n'avoir qu'un seul cpp pour tout le projet).

Bah, ça on utilise le préprocesseur pour l'éviter, non?

Francois

[Lavock]

En faite, si on met tout dans les .h, y a aucune raison que ça arrive; puisque la conséquence c'est qu'il n'y aura qu'un seul .cpp.

Le cas ou ça plante, c'est si on s'amuse à définir dans le .h et qu'on inclue celui-ci dans plusieurs .cpp (sans parler de l'inlining). Cela bug à l'édition des liens.

[Mat.M]

- Les fichiers C# sont souvent plus foutoir, et j'ai du mal en lisant le code à avoir une vue d'ensemble de ce qu'une classe est sensée faire, malgré les astuces les astuces de l'éditeur pour pallier à ce problème (en repliant le code). En C++, et sans éditeur spécifique, j'arrive à lire un .h sans problème.

On est tous 100% d'accord.
Ce que j'aime bien en C++ c'est un fichier d'include avec déclarations des classes et un fichier .cpp d'implémentation.
Ce qui est bien en C++ c'est le double scope ( :: ) ou opérateur de résolution de portée.
On sait que telle ou telle méthode d'une classe appartient à telle ou telle classe..

[nikko34]

oui moi aussi j'aime bien le .h, si c'est bien foutu on apprend beaucoup sur les classes qu'on utilise

[3DArchi]

cette raison me fait aussi me méfier des systèmes d'annotation des .h pour génération de doc semi automatique

Pourtant cela peut apporter un complément d'information non immédiatement déductible du code, non ? Pourquoi cette méfiance ? Une pollution de l'en-tête ? Un désynchronisation commentaire/code ?

[JolyLoic]

La pollution, principalement. Mais je n'ai pas vraiment de bonne alternative à proposer...

[Mac LAK]

- moins de fichiers

Ce point est exact, mais en pratique, ça n'a guère d'importance sur un très gros projet... Les inconvénients qui en découlent (cf. ci-dessous) sont largement plus gênants que ce seul et unique avantage.

- ne pas devoir modifier le header à chaque modification de méthode ou variable dans le cpp

Si c'est le cas, c'est que ta découpe est mal pensée / implémentée, ou que tu rends publics des éléments qui ne devraient pas l'être.

- compilation plus rapide

C'est faux. La compilation est au contraire plus lente, la classe étant recompilée à chaque fois qu'elle est utilisée.
Dans le cas extrême (un seul CPP et QUE des entêtes à côté), la compilation va même tout exploser car la mémoire requise pour charger l'intégralité du code résultat sera tellement énorme que tu mettras ta machine à genoux, avec un swap qui tournera à 100%.
De plus, comme il a été dit, la modification d'un entête (y compris dans la partie "implémentation") va provoquer la recompilation de TOUS les sources l'utilisant, ce qui n'arrive pas avec un CPP séparé tant que l'on ne touche pas à l'interface (cf. point précédent sur la mauvaise découpe des interfaces).

- moins de sources d'erreurs

C'est faux aussi. Tu as moins de risques d'erreurs avec une interface claire et correctement définie (que tu n'es pas censé toucher souvent), car tu peux isoler (et donc tester unitairement) ta classe de façon bien plus fiable.
En effet, sans toucher l'interface, tu n'as (théoriquement) JAMAIS besoin de recompiler ton application de test. En conséquence, tu as un test de non-régression immédiat... Avec un .H unique, tu recompiles à chaque fois, donc tu n'as pas de réel test de non-régression.
De plus, dans ce cas d'entête sans fichier source, tu vas avoir des soucis non-négligeables pour créer par exemple des DLL...

je suppose que si il y a les 2 c'est qu'il y a une bonne raison non ?

Compilation séparée, masquage d'implémentation, séparation des interfaces d'entrées/sorties du code de traitement, création de stubs, et parallélisation du travail (on fournit l'interface "vide" aux collègues, ou stubbée, et ils peuvent travailler pendant que tu réalises l'implémentation).

Perso je ne trouve pas ça pratique, d'ailleurs (corrigez moi si je me trompe) dans les autres langages tout est dans un même fichier (pour une même classe), et ils s'en sortent très bien... enfin bref

En Pascal / Delphi, qui est un langage que je connais très bien, tu n'as qu'un seul fichier par unité. Toutefois, le fichier en question sépare très nettement l'interface de l'implémentation, ce qui permet une recompilation minimale si besoin, tout comme en C/C++.
Simplement, en C/C++, ce sont deux fichiers séparés au lieu de deux sections distinctes d'un seul et même fichier, mais les contraintes sont très exactement les mêmes.
Je ne vois donc pas vraiment de différence... Et pour info, Pascal (celui de Borland) et Delphi sont parmi les compilateurs les plus rapides qui existent, si ce ne sont pas LES plus rapides tout court.

La pollution, principalement. Mais je n'ai pas vraiment de bonne alternative à proposer...

Et pourtant... Une bonne doc générée à partir des headers (via Doxygen par exemple) est largement, très largement supérieure à la lecture de l'entête "directement".
On peut y voir la doc des fonctions, bien sûr, ainsi que les relations de dépendances, et y ajouter des exemples d'utilisation piochés directement dans ton code (ex : programme de test et/ou fichier d'implémentation), le tout étant plus facile à maintenir qu'un manuel utilisateur "papier" séparé.

Dans un format adéquat (CHM sous Windows, QHP pour QT, manpages sous *nix, etc.), tu peux même directement inclure l'aide de tes modules dans celle de ton IDE favori, ce qui rend totalement inutile la "lecture" des fichiers d'entête eux-même... Bref, ce que tu fais déjà avec les entêtes standards, car je pense que comme beaucoup, sauf cas exceptionnel bien entendu, tu n'ouvres jamais les entêtes usuels (stdio.h, vector, etc.) pour voir comment c'est fait, n'est-ce pas ?

[Davidbrcz]

Et pourtant... Une bonne doc générée à partir des headers (via Doxygen par exemple) est largement, très largement supérieure à la lecture de l'entête "directement".
On peut y voir la doc des fonctions, bien sûr, ainsi que les relations de dépendances, et y ajouter des exemples d'utilisation piochés directement dans ton code (ex : programme de test et/ou fichier d'implémentation), le tout étant plus facile à maintenir qu'un manuel utilisateur "papier" séparé.

Dans un format adéquat (CHM sous Windows, QHP pour QT, manpages sous *nix, etc.), tu peux même directement inclure l'aide de tes modules dans celle de ton IDE favori, ce qui rend totalement inutile la "lecture" des fichiers d'entête eux-même... Bref, ce que tu fais déjà avec les entêtes standards, car je pense que comme beaucoup, sauf cas exceptionnel bien entendu, tu n'ouvres jamais les entêtes usuels (stdio.h, vector, etc.) pour voir comment c'est fait, n'est-ce pas ?

Je suis d'accord mais je pense plus qu'il voulait parler de la pollution du code par la documentation.

[Lavock]

La pollution, principalement. Mais je n'ai pas vraiment de bonne alternative à proposer...

Rien n'empêche de mettre une doc Doxygen ailleur que dans l'entête ><

[JolyLoic]

Bref, ce que tu fais déjà avec les entêtes standards, car je pense que comme beaucoup, sauf cas exceptionnel bien entendu, tu n'ouvres jamais les entêtes usuels (stdio.h, vector, etc.) pour voir comment c'est fait, n'est-ce pas ?

Je pense que la différence principale est que je ne modifie pas les headers de la bibliothèque standard. Alors dans ce cas, avoir un accès lecture seule à de la documentation plutôt qu'aux headers eux même, pourquoi pas. Mais pour de code que je suis appelé à faire évoluer, cette documentation inclue dans le header megène plus qu'elle ne m'aide (mais le résultat de généré par cette doc m'est bien utile quand je me place en simple utilisateur du code).

(et accessoirement, je connais un collègue qui aura plus tendance à ouvrir le .h de la SL qu'à lire la doc...)