Discussion :

[elishac]

Bonjour,

j'ai quelques petites questions concernant les .h.
Normalement ils contiennent les prototypes des .c correspondant, et une protection contre les inclusions multiples, c'est ça?
Que peuvent-ils contenir d'autre ?
Notamment, les librairies .h doivent-elles être dans le .h ou dans le .c ?
J'ai une fonction qui retourne un type évolué, cela implique-t-il que je doive écrire deux fois (dans le .c et le .h) le include de la librairie ?
Pourrait-on mettre les librairies une seule fois ? (c'est conseillé?).

Merci.

[SofEvans]

Bonsoir,

j'ai quelques petites questions concernant les .h.
Normalement ils contiennent les prototypes des .c correspondant, et une protection contre les inclusions multiples, c'est ça?
Que peuvent-ils contenir d'autre ?

Il peuvent contenir plein d'autre chose :

* Des directive de preprocesseur (#include, #define, ...)
* Des enums
* Des structures
...

J'en ai pas d'autre qui me vienne en memoire mais la liste ne doit pas etre fini.

Notamment, les librairies .h doivent-elles être dans le .h ou dans le .c ?

Si tu parle des include, apparemment, peu importe leurs place. Pour ma part, j'ai l'habitude de mettre dans le .h tout les include necessaire

J'ai une fonction qui retourne un type évolué, cela implique-t-il que je doive écrire deux fois (dans le .c et le .h) le include de la librairie ?
Pourrait-on mettre les librairies une seule fois ? (c'est conseillé?).

Euh, la, j'ai pas tout saisie ... Par type evolué, tu dois certainement parler des structures. Voici un exemple tiré d'un de mes projet si cela peut t'aider :


Le .h

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
#ifndef INDIVIDU_H
#define INDIVIDU_H
 
#include <stdlib.h>
#include <stdio.h>
 
 
typedef struct Individu Individu;
struct Individu
{
    int nombreVille;
    int *Tableau;
 
    double distanceTotal;
};
 
Individu CreationIndividu (int nombreVille, int villeDepart);
void DestructionIndividu (Individu* aDetruire);
 
void CalculerDistanceTotal (Individu* selectionner, double **TableauDistance);
void CroisementIndividu (Individu* pere, Individu* mere, Individu* enfantPere, Individu* enfantMere);
void MutationIndividu(Individu* mutant);
 
#endif

Et le .c correspondant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
#include "Individu.h"
 
/** Tout le code des prototype contenue dans le .h **/

Voila, j'espere avoir repondu a tes question ^^

[Melem]

Que peuvent-ils contenir d'autre ?

.h = déclarations (#define, typedef, déclarations de fonctions, déclarations de variables globales) + inclusions d'autres fichiers d'en-tête.

.c = définitions (définitions des fonctions, définitions des variables globales). Les fichiers .c peuvent contenir des définitions privées, c'est-à-dire visibles uniquement dans ce fichier source.

Notamment, les librairies .h doivent-elles être dans le .h ou dans le .c ?

Pas clair. Déjà un .h n'est pas une library (et en français library se dit bibliothèque et non librairie, qui en anglais se dit bookstore en anglais), mais un constituant d'une library. Reformule bien ta question.

J'ai une fonction qui retourne un type évolué, cela implique-t-il que je doive écrire deux fois (dans le .c et le .h) le include de la librairie ?

Si le type est défini dans type_evolue.h et que mon_include.h inclut type_evolue.h, alors si dans mon_fichier_source.c tu inclus mon_include.h, tu n'as plus besoin d'inclure type_evolue.h. Tu sembles ne pas avoir pas encore bien compris le fonctionnement du préprocesseur, consulte les cours, tutoriels et FAQs relatifs à ce sujet.

Pourrait-on mettre les librairies une seule fois ? (c'est conseillé?).

Tu veux dire créer un fichier d'en-tête qui inclut presque tout ? Qu'est-ce qui t'en empêche ? Et ce n'est ni conseillé ni déconseillé, c'est une question de préférence. Par contre, si certains fichiers d'en-tête ne sont pas réellement utiles, tu perds inutilement du temps à la compilation (mais le programme généré sera le même).

A propos des bibliothèques : La compilation séparée en C.

[elishac]

Merci pour les réponses.
Où est-ce que je dois mettre stdio.h ? (dans main.h où dans tous les .h du projet? Faut-il le mettre aussi dans les .c ?)
Par type évolué, je voulais dire par exemple time_t.
Où est-ce que je dois mettre le #include <time.h> ? (dans chaque .h qui utilise time_t, ou juste dans main.h ?)

Le problème c'est que je trouve qu'il est contraignant d'avoir à ce demander pour chaque fichier quels sont les bibliothèques nécessaires, j'aimerais ne les mentionner qu'une seule fois... par exemple dans main.h. C'est possible/conseillé ?
Chaque fichier .h contiendra alors un #include main.h, et chaque fichier .c le #include .h correspondant, et main.h ?

[SofEvans]

Melem t'a deja donné ta reponse

.
Tu veux dire créer un fichier d'en-tête qui inclut presque tout ? Qu'est-ce qui t'en empêche ? Et ce n'est ni conseillé ni déconseillé, c'est une question de préférence. Par contre, si certains fichiers d'en-tête ne sont pas réellement utiles, tu perds inutilement du temps à la compilation (mais le programme généré sera le même).

Donc oui, si tu veux, tu fais un "main.h" qui tu inclu partout.
Mais bon, je trouve que ca casse un peu la repartition des roles car dans mes .h, je met toutes les info et en general, 1 couple .h/.c == une definition de structure.

[elishac]

Donc vous répétez #include <stdio.h> dans tous les fichiers .c et .h ?

[SofEvans]

Pas exactement.

Pour ma part, je fait toujours un couple .c/.h (ormis "constante.h").

Ce qui fait que dans le .h que je protege, je mets toutes les declarations (prototype, strucuture, define ... et include !).

Ce .h, je l'inclu dans son .c et c'est fini.


Je t'ai donner un exemple dans un de mes precedent post.


De toutes maniere, chaque .c etant compiler separment pour donner un .o, si dans un .c donné tu veux utiliser des fonction, il va bien falloir faire un include d'un .h.

[elishac]

Donc si j'ai bien compris, vous mettez dans les .h toutes les bibliothèques nécessaires au .c correspondant, et #include "xx.h" dans le .c ?
Au final, vous avez donc écrit quasiment autant de #include <stdio.h> qu'il y a de .h ?
N'est-ce pas un travail supplémentaire que de se demander, pour chaque .h, quelles sont les bibliothèques requises pour le .c correspondant ?

[SofEvans]

N'est-ce pas un travail supplémentaire que de se demander, pour chaque .h, quelles sont les bibliothèques requises pour le .c correspondant ?

Non, c'est un choix permettant d'exporter des couple .h/.c afin de permettre leur utilisation dans un autre programme n'ayant pas de rapport avec le precedent. Je suis ainsi sur et certain que le .h/.c aura bel et bien toutes ses bibliotheque.

De plus, un .h est pour moi comme le sommaire d'un livre.
En lisant le .h, on peut se faire une idée tres precise du role de la structure sans toutefois lire l'implementation (.c).

Le listing des bibliotheque en fait partie.
Si j'utilise la SDL et que je ne vois pas dans le .h SDL_ttf, je sais que ce couple .h/.c ne gere pas l'affichage ecran, s'il y a math.h ou string.h , bla bla bla ...

C'est un choix de style, rien ne t'empeche de faire un "AllInclude.h" dans lequel tu mettra tout les include necessaire a ton programme et lequel tu incluera partout.

[elishac]

Les réponses aux deux autres questions sont oui et oui ?

Comment faire (avec gcc) pour compiler (ou en tout cas vérifier qu'il n'y a pas d'erreur de compilation, ou de include manquant, si tous les prototypes ont été recopiés dans le .h, etc) un .c et son .h ?

Où serait l'endroit le plus approprié pour décrire ce que fait une fonction ?

Comment organiser ses fichiers pour répondre à la problématique suivante : étant donné un projet qui n'est pas le sien, comment trouver le code d'une fonction (ou en tout cas son prototype et une explication de ce qu'elle fait) qui est utilisée dans le fichier qu'on est en train de lire, alors qu'elle n'y est pas définie (elle est dans un .h, mais lequel ?) ?

Désolé de poser autant de petites questions, c'est simplement que j'aimerais bien fractionner mon premier projet et je ne sais pas comment faire.

[SofEvans]

Les réponses aux deux autres questions sont oui et oui ?

Désolé, mais effectivement, c'est oui et oui.

Comment faire (avec gcc) pour compiler (ou en tout cas vérifier qu'il n'y a pas d'erreur de compilation, ou de include manquant, si tous les prototypes ont été recopiés dans le .h, etc) un .c et son .h ?

Il y a deux maniere de vous prevenir :

La premiere est la plus direct : vous vous prenez "error : undefined reference to function". La, y'a pas a titiller, il vous manque clairement un include.

La deuxieme est plus subtil, et peut passer inapercu si vous avez mal regler le compilateur : Vous avez un warning de type : "warning : implicite call of function".

Cela survient si vous avez mis dans 1.h le bon include.
Que dans 2.h vous avez inclu 1.h.
Et que dans 2.h vous utiliser des fonction de l'include de 1.h.

Où serait l'endroit le plus approprié pour décrire ce que fait une fonction ?

Comme je l'ai deja dit, le .h est pour moi une sorte de sommaire. C'est dans le .h que je met les commentaire indiquant le comportement de la fonction, ses entrer et ses sortie.

Apres, dans le .c, je met des commentaires technique sur certains point (par exemple, pourquoi je mets un tableau 2D ou 3D si ce choix est ambigue.

Comment organiser ses fichiers pour répondre à la problématique suivante : étant donné un projet qui n'est pas le sien, comment trouver le code d'une fonction (ou en tout cas son prototype et une explication de ce qu'elle fait) qui est utilisée dans le fichier qu'on est en train de lire, alors qu'elle n'y est pas définie (elle est dans un .h, mais lequel ?) ?

Alors la, aucune idée. Ca depend de comment a coder la personne. Je sais que sous code::block, en faisant un click droit sur une fonction, on peut selectionner "trouver la declaration" (ou un truc du meme gout). En general, sur les bibliotheque tel que la SDL, ca marche plutot bien. Mais ce n'est pas sur.

Bref, a toi de t'amuser pour trouver ca.

Désolé de poser autant de petites questions, c'est simplement que j'aimerais bien fractionner mon premier projet et je ne sais pas comment faire.

Désolé d'etre pessimiste a tes yeux, mais si c'est vraiment ton premier gros projet, tu vas forcement raté l'organisation car tu n'as certainement pas encore trouver ton style de codage.
Ca viendrat petit a petit avec l'experience. Lorsque tu aura fini ce premier projet, tu aura deja un certain apercu des probleme que pose ton organisation :

par exemple, tu as écopé une trentaine de fois des undefined reference car le systeme d'include que tu as choisi n'est pas a ton gout et tu as du mal avec.
Tu as nommé un fichier Individu.c mais il contient des fonction n'ayant rien a voir avec des Individu ...
Bref, le style de codage est quelque chose qui se forme petit a petit. N'essaye pas de copier les autre, il faut trouver son propre style.

Mais rien ne t'empeche d'essayer de reunir pleun d'info avant de franchir le pas, evidemment

Bon courage pour la suite.

[elishac]

Merci pour les réponses, elles me sont utiles.
Pour la seconde question, je me suis mal exprimée. Je voulais demander quelle était la ligne de commande pour compiler un tel fichier ; jusqu'à présent je n'ai compilé que des programmes avec des main, et sans main ça me renvoie des erreurs, il y a sans doute une option particulière pour compiler un fichier sans main ?


J'ai compris l'intérêt de mettre plusieurs fois la même bibliothèque dans des fichiers différents, au lieu d'une seule fois (pour pouvoir facilement exporter le fichier .c ). Mais comment vérifier que toutes les bibliothèques nécessaires au fonctionnement d'un fichier fichier1.c sont inclues dans fichier1.h, si ce fichier1.c inclut également fichier2.h ? Par exemple, fichier1.c nécessite stdio.h, mais fichier1.h n'a pas stdio.h ; en revanche, fichier1.h inclut fichier2.h, qui lui contient stdio.h ; le compilateur peut-il s'en rendre compte et m'en informer, afin que je puisse exporter fichier1.c sans que ça bug?


D'autres petites questions de débutant me sont venues à l'esprit :

Nommer le .h comme le .c, c'est simplement pour s'y retrouver, mais ce n'est pas nécessaire, si ? (pour inclure une fonction définie dans un autre fichier, on inclut son .h, donc son prototype, mais à quel moment la fonction elle-même est-elle renseignée?)

Si #include <stdio.h> est écrit dans plusieurs fichiers, il ne sera quand même ajouté qu'une seule fois ?

En ce qui concerne le nom de la constante permettant l'inclusion réciproque, j'ai vu qu'il était de coutume de mettre des 2 traits en bas avant et après, et un après le H, le tout en majuscule.
Pourquoi utiliser des majuscules ? Pourquoi des traits en bas avant et après ? Pourquoi pas un simple .h au lieu de _H ? Quelle est la coutume de nommage de la constante lorsque le nom du fichier (qui ne peut pas contenir d'espaces, si?) contient lui-même des traits en bas ?


Je suis par ailleurs à la recherche d'un ide. Lequel est celui le plus utilisé ? Le plus facile à prendre en main ? Le meilleur () ? Lequel me conseillez-vous ?
Un ide permet-il d'automatiser la création des .h (qui me semble assez systématique, pour une grande partie en tout cas - recopie des prototypes, protection, etc.) ?

Merci.

[SofEvans]

Bonsoir,

Cette histoire vous embete, hein ?

Pour la seconde question, je me suis mal exprimée. Je voulais demander quelle était la ligne de commande pour compiler un tel fichier ; jusqu'à présent je n'ai compilé que des programmes avec des main, et sans main ça me renvoie des erreurs, il y a sans doute une option particulière pour compiler un fichier sans main ?

Ah ca, je suis désolé, mais je n'ai pas encore eu besoins de compiler un .c separement (les .h n'etant pas compiler réellement).
Donc, je ne saurais repondre a votre question.

Voici cependant une piste : Je sais que l'IDE visual est capable de le faire contrairement a l'IDE Code::Block.

J'ai compris l'intérêt de mettre plusieurs fois la même bibliothèque dans des fichiers différents, au lieu d'une seule fois (pour pouvoir facilement exporter le fichier .c ). Mais comment vérifier que toutes les bibliothèques nécessaires au fonctionnement d'un fichier fichier1.c sont inclues dans fichier1.h, si ce fichier1.c inclut également fichier2.h ? Par exemple, fichier1.c nécessite stdio.h, mais fichier1.h n'a pas stdio.h ; en revanche, fichier1.h inclut fichier2.h, qui lui contient stdio.h ; le compilateur peut-il s'en rendre compte et m'en informer, afin que je puisse exporter fichier1.c sans que ça bug?

J'ai deja repondu, je vais donc insister. Si cependant cela n'est toujours pas clair, n'hesiter pas.

Comment faire (avec gcc) pour compiler (ou en tout cas vérifier qu'il n'y a pas d'erreur de compilation, ou de include manquant, si tous les prototypes ont été recopiés dans le .h, etc) un .c et son .h ?

Il y a deux maniere de vous prevenir :

La premiere est la plus direct : vous vous prenez "error : undefined reference to function". La, y'a pas a titiller, il vous manque clairement un include.

La deuxieme est plus subtil, et peut passer inapercu si vous avez mal regler le compilateur : Vous avez un warning de type : "warning : implicite call of function".

Cela survient si vous avez mis dans 1.h le bon include.
Que dans 2.h vous avez inclu 1.h.
Et que dans 2.h vous utiliser des fonction de l'include de 1.h.

Je me permet de faire une correction. Je n'utilise pas les ligne de commande pour compiler.

Nommer le .h comme le .c, c'est simplement pour s'y retrouver, mais ce n'est pas nécessaire, si ? (pour inclure une fonction définie dans un autre fichier, on inclut son .h, donc son prototype, mais à quel moment la fonction elle-même est-elle renseignée?)

Tout dabord, non, ce n'est pas obliger d'avoir le meme nom pour le .c et le .h.
Voila comment ca se passe.

Quant tu veux compiler, le compilateur ne regarde QUE les .c : dans ces .c, tu as mis des include vers des .h, comment ca marche ?
C'est simple, include signifie " prendre tout ce qu'il y a dans le .h concerner et remplacer la ligne include par le contenue". C'est en gros une sorte de copier coller.

La fonction est renseigner lorsque tout les .c sont compiler. La, je manque de connaissance, donc je ne m'aventure pas plus.

Si #include <stdio.h> est écrit dans plusieurs fichiers, il ne sera quand même ajouté qu'une seule fois ?

Non, a chaque fois que tu met include, tu fais un copier/coller. Donc, il y aura autant de copier/coller que de include, si je ne m'abuse. Par contre, je ne peux pas garantir a 100% la veracité de mes propos. Le mieux serait d'attendre que quelqu'un de bon vienne confirmer (Diogene, Medinoc, Melem et tant d'autre).

En ce qui concerne le nom de la constante permettant l'inclusion réciproque, j'ai vu qu'il était de coutume de mettre des 2 traits en bas avant et après, et un après le H, le tout en majuscule.
Pourquoi utiliser des majuscules ? Pourquoi des traits en bas avant et après ? Pourquoi pas un simple .h au lieu de _H ? Quelle est la coutume de nommage de la constante lorsque le nom du fichier (qui ne peut pas contenir d'espaces, si?) contient lui-même des traits en bas ?

Alors, ceci est un style de codage qui est presque devenu une reference. Quand on declare une variable, generalment c'est tout en minuscule, et lorsqu'on fait des constante, c'est tout en majuscule.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
int variable = 0;
int const CONSTANTE = 20;

Or, un define peut etre assimiler a une constante. D'ou le fait de le mettre en majuscule. Apres, on met "_H" pour le differencier des autre define et ainsi dire : " ce define protege de la multi inclusion".

On ne peut pas mettre "." dans un define par contre, d'où l'utilisation de l'underscore.

en general, on fait

NOMDUFICHIER + _H (ou + _H_)

Si le nom du fichier contient des espace, tu peux faire

NOM_DU_FICHIER + _H (ou + _H_)

Tu peux aussi faire ca, mais c'est moins courant :

nomDuFichier + _h ( ou + _h_)


C'est a toi de voir, c'est un style comme un autre et c'est parfaitement valable.

Je suis par ailleurs à la recherche d'un ide. Lequel est celui le plus utilisé ? Le plus facile à prendre en main ? Le meilleur () ? Lequel me conseillez-vous ?
Un ide permet-il d'automatiser la création des .h (qui me semble assez systématique, pour une grande partie en tout cas - recopie des prototypes, protection, etc.) ?

Il n'y a pas de meilleur IDE que les autre. Il y a ceux qui sont plus conseiller que d'autre.

Bon, il faut savoir qu'il y en a deux qui sont reccurent :

Code::Block
Visual Studio


Je te deconseille d'utilise Dev C++ qui est completement dépasser selon moi (et plein d'autre).

Mon preferé apres avoir utilisé les deux est Code::Block, car j'ai eu des bizarrerie avec Visual, mais je connais plein de gens qui dise la meme chose a l'encontre de Code::Block.

Bref, l'IDE que je conseil est Code::Block mais comme tout, ce n'est qu'une question d'habitude.

Voila Voila
Bonne continuation.

[Melem]

@elishac : tu sais que tu aurais pu ne pas avoir eu à poser 99,9% des tes questions si tu avais dès le départ suivi le lien que je t'ai donné ? Je le reposte au cas où tu ne l'as pas vu : [Tutoriel] La compilation séparée. Sans compter les autres ressources disponible sur ce site concernant ton problème ...

[elishac]

SofEvans, merci beaucoup pour les réponses, elles m'ont énormément aidées.

Melem, pour vous répondre, j'ai lu votre tutoriel, mais je n'y ai pas trouvé les informations que je souhaitais. Peut-être l'information n'était-elle pas claire et je ne l'ai pas comprise, ou alors elle n'y était simplement pas du tout (il n'y a qu'un seul petit paragraphe, I-D, je crois, sur les en-têtes - il m'étonnerait que dans ce petit paragraphe il y ait 99.9% des nombreuses questions que j'ai posées). Si on était censé ne pas poser toutes les questions qui sont disponibles "sur simple recherche", il n'y aurait pas une seule question dans le forum. De nos jours, tout se trouve sur Internet. Il faut faire la part des choses. J'ai fait quelques recherches, et je n'ai pas trouvé ce que je cherchais, donc j'ai posé mes questions sur le forum.

Désolé pour ce long message.

Merci à tous pour votre aide pour résoudre mon problème, je reviendrai si j'ai d'autres questions.