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.

[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

[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

[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.

[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...)

[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 ><