Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Pourquoi certain fichier d’en tête n'ont pas besoin de fichier source associé?
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 !
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...
ou sont les sources?
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 ?
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.
ok
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 .
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
on t'a menti, le nom du fichier ne compte pasEnvoyé par chmimi05
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)
merci pour vos réponse
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 ??
En fait, le lien, il est relativement facile à trouver:(...)
PS : pour nikko34 qui me dit "on t'a menti, le nom du fichier ne compte pas"
On m'aurai menti ??
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
ok
Je te remercie encore une fois koala01 pour ta réponce, cela confirme ce que je ne savais plus :p.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager