Bonjour,

Le programme que je développe actuellement va probablement compter pas mal de lignes de code et pour des questions de lisibilité je pense séparer le source en plusieurs fichiers et j'ai 2 questions :
- pour que les différents fichiers soient pris en compte il suffit bien de faire des "include" dans le fichier principal?
- comment organiseriez vous ces fichiers, lequel contient quoi?

Merci

Pas vraiment... Tu mets dans le même source .c des fonctions qui ont un rapport entre elles et dans les .h (que tu "inclus" dans les autres sources) tu déclares simplement les fonctions qui doivent être appelées depuis ailleurs.

Chacun fait ce qu'il veut mais je peux t'expliquer ma méthode :
- main.c qui contient le PilotMain(), les fonctions d'initialisation et de nettoyage (au démarrage et à l'arrêt de l'application) et la boucle de messages.
- utility.c contient des utilitaires (c'est à peu près le mêmes pour tous mes programmes). Par exemple la gestion du DIA, de la HR sony...
- des fichiers utilitaires par grande "fonction" (que je réutilise aussi régulièrement). Exemple : utilbeam.c pour la gestion du beam, utilweb pour les fonctions d'accès internet/web...
- un source par "form" de l'application.

Euh non. Il faut plutot faire differents .c et la phase de construction du .prc à partir des .c se fait comme suit :
- on compile les .c, ce qui donne des .o
- on 'assemble' les .o et les resources pour donner le .prc



Moi en général j'ai :
- un main.c qui contient le PilotMain et l'handler d'evenement de l'appli,
- un utils.c qui contient des routines transverses génériques, que je réutilises dans tous mes projets,
- en général un .c par formulaire,
- en général j'ai un .c par grand thème (comme accès à la base de données de l'appli, ...)

("c'est mon choix" d'organisation des sources, c'est tres probablement criticable, mais bon :p)

Eddy

et le make prends automatiquement tous les .c lors de la compilation?

Si tu le dis à make, oui
Par exemple pour snap j'ai dans mon Makefile les lignes suivantes :


et quelque part, indirectement, j'ai Snap.prc qui depend des .o, avec quelque chose comme :


J'espère être clair dans mes explications,
Eddy

Merci à vous deux je vais tester

Je suis en train d’essayer d ‘appliquer vos recommendations, mais j’ai une question sur les variables globales.
Par exemple, actuellement j’ai des variables globales pour la structure de mes enregistrements que j’utilise dans toutes les fonctions. Si je scinde mon source en plusieurs fichiers, et que je déclare ces variables au niveau d’un « main » dans lequel sont référencées (par un include) les fonctions contenus dans les autre fichiers sources elle ne resteront « globale » qu’au niveau du « main » ou le seront elle pour les autres aussi?

Tu les déclares en "extern" dans ton .h : elles seront visibles de tous les sources où le .h est inclus.

Il me semble (à confirmer par des spécialistes du C) :

- si tu definis une variable dans un fichier, tu peux acceder à cette variable dans un autre .c en declarant la variable avec le mot clé extern. Par ex :
fichier 1

fichier 2 :


- utiliser les variables globales c'est pas bien. Moi j'ai aucune variable globale dans mes codes. Je préfère passer des variables ou des structures qui vont bien d'une fonction à une autre.

(voilà, je dis tout ca de tête, pas 100% sûr de moi)

Eddy

Bon j'ai un problème; les .o sont bien générés mais ensuite j'ai des erreurs "undefined reference" comme si mes .h n'avaient pas été pris en compte.

Est ce que ça peut venir du makefile?

A tout hasard mon makefile

J'ai lu en diagonale ton makefile ca me semble correct. Une idée, comme ca, ca viendrait pas du fait que tu declares partout ta variable 'extern' mais qu'elle est définie nulle part ?
(ca expliquerait que la compilation reussise mais pas l'edition de lien)

(sinon tu peux me mailer ton projet que j'y jette un oeil ? je comprendrais parfaitement que tu le veuilles pas)

Eddy

Tu entends quoi par définie nulle part? En plus j'ai ce message aussi pour toutes les fonctions appelées.

Si ta variable n'est déclarée qu'en 'extern', elle n'existe pas, tu as simplement dit partout qu'elle était définie ailleurs. Il doit y avoir un source (et un seul) où la variable est réellement définie

Je voulais dire (mais je me trompe probablement), que la directive extern signale au compilateur que la variable dont il est question est définie ailleurs (dans un autre module).
Si tu as des extern Uint8 variable; dans tes sources, il te faut quelque part un Uint8 variable.
Mais si tu dis que les fonctions aussi ne sont pas trouvées, le problème doit être autre. Fausse piste.

Eddy

Ca doit quand même bien vous faire rigoler mes questions car quand je vois les réponses, je qualifie mieux le niveau de la question .

Bon je corrige et je vous tiens au courant (ceci dit, j'ai aussi le problème sur des fonctions appelées)

Je suis sur que tout le monde était impatient de connaître le résultat. Eh bien ca y est j'ai réussi à "éclater" mon source en plusieurs fichiers et à les compiler (j'ai retrouvé les bugs que j'avais avant )

Un grand merci à Eddy, qui a passé du temps avec moi sur AIM, a regardé mes fichiers et à trouvé l'erreur (j'avais déclaré pas mal de mes fonctions en "static", donc forcément elles ne pouvaient pas être reconnues à l'exterieur )

Changes aussi cette ligne dans ton Makefile.

Quand tu écris ton code pense toujours à l'écrire comme si quelqu'un d'autre le modifiera. Car si tu t'arrettes quelque temps de le maintenir, quand tu y retournera tu auras du mal à t'y remettre.

Comme Eddy l'a dis, n'utilise pas les variables globales sauf nécessité absolue.
Utilises des noms de fonctions claires et qui permettent de retrouver le fichier qui les contient (ex: MainForm.c (MainFormHandlerEvent(), MainFormOpen()...))
utilises le plus possible le mots static, çà permet de voir les dépendences entre fichiers.
hierarchises ton projet:
un répertoire racine, avec un Makefile principal.
un répertoire src, avec un Makefile
un répertoire rcp, avec un Makefile
un répertoire doc, avec un Makefile