Discussion :

[chmimi05]

Bonjour,

En effet je suis en train d'essay� de coder un plug in pour Winamp, je r�cupere quelque fichier de base pour ne pas r�invent� la roue, et je tombe sur un projet qui contient un fichier source : Svis.c et un fichier d'en tete vis.h, j'aimerais donc savoir pourquoi si il y vis.h il n'y � pas obligatoirement de vis.cpp.

Merci de vos r�ponces !

[M�dinoc]

Il n'y a aucune relation obligatoire entre un fichier d'en-t�te et un fichier source.
Il peut y avoir N en-t�tes et M sources, sans qu'on puisse faire la moindre supposition sur une relation entre N et M.

Typiquement, un header ne d�crivant que des fonctions templates ou inline n'aura pas de fichier source "associ�".
�galement, on peut avoir 1 fichier d'en-t�te pour un projet de N sources...

[chmimi05]

On ma dit que un fichier d'en tete contenait les declarations d'un fichier source portant le meme nom que celui ci ...il y a donc des exceptions comme tu me dis mais alorss dans ce cas ou se trouve les sources des fonctions dont les prototype sont dans les headers ? dans les .dll ? dans des .lib ?

[Ksempac]

Un exemple simple o� il n'y a qu'un .h :

si tu fais une classe abstraite avec uniquement des d�clarations de m�thodes virtuelles pures tu as seulement un .h et pas de .cpp : L'impl�mentation des m�thodes se fera dans les classes d�riv�es qui auront leur .h et leur .cpp.

[chmimi05]

Ok ksempac et merci pour ta r�ponce , j'aimerais alors savoir si mon .h est un header de classe virtuel pure � savoir que celui ci contient comme code :

2 typedef struct, un typedef et un #define .

[Ksempac]

Une classe abstraite est une classe avec une ou plusieurs methode virtuelles pures. Les methodes virtuelles pures sont d�finies comme ceci :

virtual typeretour methode(parametres) = 0;

Rien a voir avec ton exemple. D'ailleurs au vu de ta question, je me demande si tu comprends la notion de classe et de m�thode...

Ton .h ici sert visiblement a d�finir des structures et des types qui sont utilis�s par plusieurs .cpp : il serait d�bile (et d'ailleurs incorrect) de faire plusieurs fois les d�clarations de ses structures dans chaque .h

[nikko34]

On ma dit que un fichier d'en tete contenait les declarations d'un fichier source portant le meme nom que celui ci ...

on t'a menti, le nom du fichier ne compte pas

[koala01]

Salut,

les fichiers h sont les fichiers d'entete qui contiennent... des d�clarations...

Les fichiers cpp sont des fichiers de code qui contiennent... des d�finitions...

Il est vrai qu'il est courent d'avoir un seul fichier de d�finition par fichier de d�claration... mais...

Quand on y pense bien, ce qui importe, c'est surtout que chaque fichier de d�finition dispose des d�clarations des classes/structures/fonctions qu'il impl�mente/appelle/utilise...

Et il reste un fait ind�niable: tu auras toujours plus facile de t'y retrouver dans 10x100 lignes que dans 1x1000...

De plus, un fichier qui de 100 lignes utiles prendra *vraissemblablement* beaucoup moins de temps � etre (re)compil� s'il doit l'�tre qu'un fichier qui en contient 1000...

Tout cela fait qu'il n'est pas impossible d'imaginer d'avoir l'impl�mentations des fonctions d�clar�es dans un seul fichier d'entete dans plusieurs fichiers de d�finitions...

Tu pourrais meme d�cider, si le coeur t'en disait, de mettre toutes les d�clarations dans un seul et meme fichier d'entete et de mettre les impl�mentations/d�finitions des diff�rentes fonctions seules dans des fichiers diff�rents...

Dans les projets importants, il n'est vraiment pas rare de constater qu'il y a, dans certains dossiers, plus de fichiers d'entete, et dans d'autres, plus de fichier d'impl�mentation (si tu en as l'occasion, regarde les sources de QT pour t'en convaincre )

[chmimi05]

Ce qui importe comme le dit Koala01 :"c'est surtout que chaque fichier de d�finition dispose des d�clarations des classes/structures/fonctions qu'il impl�mente/appelle/utilise..."

Je vous remercie pour toutes vos r�ponse , j'y voit plus claire maintenant.

PS : pour nikko34 qui me dit "on t'a menti, le nom du fichier ne compte pas"
On m'aurai menti ?? c'est peut etre moi qui es du mal comprendre mais il me semble que ds un projet c++ il y a bien un lien entre deux fichier qui porte le meme nom( ex�pter l'extension ) mais je me souviens plus exactement lequel, mais je suis persuad� qu'il y en a un ...

[koala01]

(...)
PS : pour nikko34 qui me dit "on t'a menti, le nom du fichier ne compte pas"
On m'aurai menti ?? c'est peut etre moi qui es du mal comprendre mais il me semble que ds un projet c++ il y a bien un lien entre deux fichier qui porte le meme nom( ex�pter l'extension ) mais je me souviens plus exactement lequel, mais je suis persuad� qu'il y en a un ...

En fait, le lien, il est relativement facile � trouver:

Bien qu'il soit tout � fait possible d'envisager de programmer avec un outil aussi simple que le bloc note, ou, � peine plus �volu� comme gedit/kedit (linux), une grosse majorit� des gens programmes... en utilisant des EDI (que ce soit VC de crosoft, BCBuilder de borland, code::blocks ou tant d'autres)...

Or, les diff�rentes EDI sont, pour la plupart, programm�es pour, quand tu cr�es une classe, et sauf ordre contraire, cr�er un fichier d'entete et un fichier d'impl�mentation dont le nom est... celui de la classe cr��e...

On a donc pour ainsi dire d'office les deux fichiers, *la plupart* se contentent de rajouter les membres n�cessaires dans le fichier d'entete et les d�finitions des fonctions membres dans le fichier d'impl�mentation...

Et, comme il n'y a vraiment que si l'on se rend compte que certaines d�clarations d'un fichier d'entetes sont n�cessaires dans de nombreux fichiers dans lesquels une bonne partie des d�clarations est inutile qu'on envisagera de les s�parer, mais que, par contre, il est rare que quelqu'un estime que le fichier d'impl�mentation devient � ce point important qu'il serait utile de le diviser en deux, on en arrive souvent � une situation dans laquelle il y a plus de fichiers d'entetes que de fichier d'impl�mentation

[chmimi05]

Je te remercie encore une fois koala01 pour ta r�ponce, cela confirme ce que je ne savais plus :p.