Version imprimable
En fait dans les fichiers.h j'ai inclu toutes mes fonctions auquelles je fais appel dans le menu principal, j'ai aussi un fichier que j'ai appelé structure.h qui contient toutes mes structures...Citation:
Envoyé par Skyrunner
Rassurez moi, il n'y a aucun probleme à mettre des fonctions dans un fichier.h??
J'ai testé #include <fic.dtc> ça marche:mouarf: (Merci)!!
Un fichier d'entête sert à :Citation:
Envoyé par landryx
-partager des structures publiques ;
- des types publiques ;
- des prototypes de fonctions (donc pas la fonction complète)
- des macros partagées (ça n'arrive normalement pas souvent, mais ça peut être utile)
Car si tu ne t'en sers pas que pour ça, tu perds tout l'interêt de la compilation multi-fichier et l'interêt de "cacher" les données privées dans un fichier objet .o
Je te ramène encore une fois à ce lien :
http://emmanuel-delahaye.developpez.....htm#organiser
Mettre toutes tes structures dans un fichier structure.h, c'est moyen moins. Déjà, il est possible qu'il y ait des structures privées, dans ce cas, il faut les mettre dans le fichier .c Et il est très possible que certaines structures soient totalement en relation avec un module (fichier .h plus fichier d'implémentation .c), dans ce cas, il faut le mettre dans le fichier .h correspondant.
Outre le fait que ce n'est pas le role d'un fichier d'entete, si il y a un probleme le jour ou tu vas inclure ce .h dans deux fichiers du projet. LA fonction sera definie deux fois.Citation:
Envoyé par landryx
Donc c n'est pas si dramatique puisqu'il ya un moyen d'eviter les conflits de déclaration...
Effectivement, ce n'est pas dramatique... pas plus que de se promener à pied sur l'autoroute (il y a toujours un moyen que les voitures t'évitent)... :aie:Citation:
Envoyé par landryx
Dans les deux cas, je te le déconseille quand même ! ;)
ok merci!! je crois que j'ai à peu pres compris.
Il faut savoir qu'en C, on peut faire beaucoup de choses, car c'est une langage peu formalisé et sa définition ne donne quasiment aucune indication sur son usage. C'est donc en analysant les façons de travailler des programmeurs depuis les 30 dernières années, au travers, notamment, de forums de discussions comme comp.lang.c (Usenet), qu'il a finalement été possible de dégager un certain nombre de 'Bonnes Pratiques'. Le fait de bien séparer l'interface (.h) de l'implémentation (.c), en est une.Citation:
Envoyé par landryx
En Turbo Pascal ou en Ada, ces notions sont inscrites dans les gènes du langage. En C, il a fallut un peu interpréter les intentions des auteurs, puis du comité de normalisation.
Bien sûr, on peut toujours faire autrement, mais ce serait se priver de l'expérience acquise...
Mon site essaye de répertorier un certain nombre de ces 'Bonnes Pratiques'. Les buts recherchés sont :
- Lisibilité
- Modularisation
- Tests unitaire
- Réutilisation
- Fiabilité
Ils n'ont rien d'idéologique ni de sectaire. Ils découlent du simple bon sens.