Discussion :

[LeNoob]

Salut!

Voila j'ai un projet contenant plusieurs fichiers :

- main.c
- main.h
- main_ext.h
- fonctions.c
- fonctions.h
- ...

Mon problème c'est que pour éviter le 'multi define' j'ai fais une copie du fichier main.h nommé main_ext.h qui comme son nom l'indique correspond au même variable de main.h mais défini en extern.
Ce qui m'embète c'est qu'au bout d'un moment sa devient pénible de devoir éditer 2 fichiers pour faire une modification (en plus d'être rapidement une source d'erreur!). je me demandais donc s'il n'y avait pas un autre moyen pour éviter le 'multi define' ou pour remplacer/générer mon main_ext.h.

merci pour votre aide.

[Médinoc]

Pas à ma connaissance: Une variable globale doit être déclarée dans un fichier d'en-tête et définie dans un fichier source dédié.

Je ne vois aucune alternative.
Ah si! Comment ai-je pu oublier celle-là:

Ne pas utiliser de variables globales.

[3DArchi]

Fondamentalement, même avis que Médinoc: éviter les variables externes. Passer par une interface fonctionnelle.
Sinon, pour un pansement sur une jambe de bois bancale :
dans main.h

Code :

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

1
2
3
4
5
6
7
8
 
#ifndef _D_MAIN_IMPL_
#define _D_MAIN_EXPORT_	extern
#else
#define _D_MAIN_EXPORT_
#endif
 
_D_MAIN_EXPORT_ int g_Main_iMaVariable ;

Dans ton main.c

Code :

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

1
2
3
 
#define _D_MAIN_IMPL_
#include "main.h"

Dans un autre.c

Code :

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

1
2
3
 
/* Pas de définition de _D_MAIN_IMPL_ */
#include "main.h"

[cmoibal]

mais normalement tu peut faire une include dans le fichier main_ext.h

exemple:

Code :

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

1
2
3
4
5
6
7
8
9
 
#ifndef MAIN_EXT_H
#define MAIN_EXT_H
 
#include "main.h"
 
.....
 
#endif // MAIN_EXT_H

[LeNoob]

@ Médinoc : en faite c'est de la programmation sur dspic, le programme est assez volumieux et doit contenir l'état de pas mal de capteurs, servos, moteurs,....bref je ne peux pas me permettre de passer toutes ces infos dans les fonctions par des paramètres...même si tout est bien organisé à l'aide de structures,... le code deviendrait illisible

@ 3DArchi : merci pour cette solution mais le 'multi define' revient

@ cmoibal : si je fais ça j'ai un problème de 'multi define'....

[Médinoc]

OK, si c'est de l'embarqué ça s'excuse

[souviron34]

Pas à ma connaissance: Une variable globale doit être déclarée dans un fichier d'en-tête et définie dans un fichier source dédié.

Non, ce n'est pas obligé

Il suffit que tu les définissent en local dans le main, et en externes dans le .h inclus dans les autres fichiers...

Cependant, dans ce cas, cela évite bien le multi define, mas c'est moins joli et maintenable. Mais ton affirmation est fausse. C'est juste de la bonne pratique..

Je ne vois aucune alternative.
Ah si! Comment ai-je pu oublier celle-là:

Ne pas utiliser de variables globales.

Là 100% d'accord

Maintenant, en ce qui concerne l'embarqué, je ne vois pas trop ce qui empêcherait de faire appel à des paramètres d'une structure passée en paramètre....

Ce que je ferais dans ce cas c'est (à condition d'avoir un minimum de mémoire) de stocker tous les paramètres "globaux" dans une structure, et soit de la passer en paramètres aux fonctions des autres modules (le plus élégant et correct), soit, plus simple mais moins élégant et moins correct, de faire une fonction qui stocke localement l'adresse de la structure dans chaque module.

Ainsi, la seule définition globale serait la définition de la structure (donc pas de multi-define), et ce serait "relativement" dynamique (l'adresse serait par exemple stockée dans une variable globale à chaque module..)

[LeNoob]

Maintenant, en ce qui concerne l'embarqué, je ne vois pas trop ce qui empêcherait de faire appel à des paramètres d'une structure passée en paramètre....

Comme tu l'as évoqué la mémoire peut être un soucis sur des microcontroleurs de faible mémoire...du coup le code devient difficilement portable par la suite. Je suis totalement d'accord avec vous, il faut éviter les variables globales (d'ailleurs si c'était un programme win32 je n'aurais même pas ouvert ce topic^^), mais dans le cas que je suis entrain de traiter, je ne peux me permettre d'envoyer à une fonction (et il n'y en a pas qu'une ) une structure globale par exemple, vous n'imaginez même pas la taille de la structure et le manque de praticité (puis surtout pour tout retoucher le code enormement long...).

[souviron34]

ben de toutes façons c'est global.

Donc tu as tous tes paramètres en mémoire.

[3DArchi]

Une question : en quoi le multi-define te gène ? D'autant, que j'avoue ne pas voir beaucoup d'autres solutions : soit tu gère deux fichiers à la main (et risque de divergence/erreur), soit tu utilises le multi-define (ce qui 'conceptuellement' revient à gérer deux fichiers par le compilateur).

[wiztricks]

Bonsoir,

Je n'ai pas tout compris.

Dans un .h ne devraient figurer que les # define, des extern, et des déclarations de prototypes de fonctions.

Fonctions et variables déclarées extern devront figurer dans un seul fichier .c - sinon, çà va raler "multi-define".

Donc plutôt que:

Mon problème c'est que pour éviter le 'multi define' j'ai fais une copie du fichier main.h nommé main_ext.h qui comme son nom l'indique correspond au même variable de main.h mais défini en extern.

Il faudrait déplacer nombre de déclarations de variables dans un .c et ne garder dans le .h que les extern.

Qu'est ce que j'ai loupé?
- W

[Mat.M]

Ce qui m'embète c'est qu'au bout d'un moment sa devient pénible de devoir éditer 2 fichiers pour faire une modification (en plus d'être rapidement une source d'erreur!). je me demandais donc s'il n'y avait pas un autre moyen pour éviter le 'multi define' ou pour remplacer/générer mon main_ext.h.

merci pour votre aide.

Cela ne serait pas plus judicieux de faire des .lib de codes ou bibliothèques liées statiquement ?

[3DArchi]

Qu'est ce que j'ai loupé?
- W

Dans ce cas, au lieu de gérer un main.h et un main_ext.h, il y aura une définition dans main.h et une déclaration dans main.c: à nouveau le problème de redondance....

LeNoob: Je ne comprends par ton problème de compil. Pourrais-tu être plus précis. Peut-être la solution que tu as adopté n'était pas adapté à l'erreur que tu avais.

[wiztricks]

Dans ce cas, au lieu de gérer un main.h et un main_ext.h, il y aura une définition dans main.h et une déclaration dans main.c: à nouveau le problème de redondance....
...

Merci pour cette explication.

L'utilisation des "# define" que vous avez suggéré précédemment est une solution.

Je crois que plus fondamentalement, ce qui me gène c'est que les headers définissent les interfaces et éventuellement des variables globales.
A priori, ce sont des parties "stables" pour autant qu'on ait arrêté le "design".

Si on designe au fil de l'eau (ce n'est pas un reproche, parfois il faut explorer), normal que ces frontières bougent.

Dans ce cas, il est peut être sage d'attendre que le design de la chose se dégage avant de s'amuser à découper cela en modules.

- W