Discussion :

[troumad]

Bonjour

Je réfléchis pour alléger un programme, un projet avec beaucoup de fichiers ".c", que j'ai fait en C avec gtk3. Je le reprends à zéro.

J'ai un tas de paramètres que j'initialise au départ en lisant des fichiers (beaucoup). Si je ne les déclare pas comme variables globales, je dois me débrouiller pour les passer en paramètre à chaque appel de fonction. Et ça alourdit énormément les transferts et l'écriture du code.

Je me demande s'il ne serait possible de définir des variables globales pour qu'elles ne soient modifiables que par les programmes d'un fichier ".c" et pas par les autres où elles seraient considérées comme des constantes.

Je sais, les variables globales ne sont pas recommandées, mais ça allègerait beaucoup la structure du programme.

[imperio]

Pour faire ce que tu veux, j'aurais tendance à passer par une fonction :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
// fichier avec la variable globale
int variable_globale;
 
int get_variable_globale() {
    return variable_globale;
}
 
int set_variable_globale(int v) {
    variable_globale = v;
}
 
#define VARIABLE_GLOBALE get_variable_globale()

Mais après, si l'utilisateur veut y regarder d'un peu plus près, il pourra toujours la modifier... Cela ça peut peut-être te fournir une piste, qui sait ?

[troumad]

@imperio :
On ne pourra la modifier à partir des autres fichiers que si "set_variable_globale" est facilement* disponible. Je pense que cette astuce devrait aussi marcher avec des structures.

* : ne pas le mettre dans le ".h" correspondant, mais si on le veut vraiment, on pourra toujours mettre son prototype dans le début d'un ".c". Ceci dit, je pense que c'est une protection déjà pas mal.

@phil1981 :
Mon but est d'éviter de passer des paramètres à des fonctions. Ce n'est pas toujours simple (léger) avec gtk. Il y a les paramètres locaux à passer + les globaux à gérer. Ça devient facilement lourd.
Je suis bien d'accord avec toi sur les variables globales. C'est pour ça que je voulais mettre des gardes-fou.

[foetus]

Je ne sais pas si cela est fonctionnel, ... mais c'est la technique du pauvre

extern.h:

Code :

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

1
2
extern int g_a;
extern int g_b;

extern.c:

Code :

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

1
2
int g_a;
int g_b;

global.h:

Code :

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

1
2
3
4
5
// Only read-only
 
#define GET_A g_a
// or
int get_b() { return g_b; }

full_global.h:

Code :

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

1
2
3
4
5
#include "global.h"
 
void set_a(int new_a) { g_a = new_a; }
 
void set_b(int new_b) { g_b = new_b; }

Édit: leternel a raison pas de fichier extern.h
Cette technique [qui doit être suivie par le développeur, il n'y aucune protection du compilateur] je l'ai modifié de celle pour avoir les méthodes protected en Objective-C

Ensuite avec la solution de leternel, mettre que les procédures/ fonctions setters dans le .c ne doit fonctionner que pour des appels dans le fichier .c lui-même: à tester donc

[ternel]

Pour le coup, surtout pas d'extern, qui donnent directement accès à la variable.
L'objectif, c'est que les utilisateurs n'ont pas accès du tout à la variable.

globals.h:

Code :

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

1
2
3
// Only read-only
int get_a();
int get_b();

globals_a.h:

Code :

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

1
2
#include "global.h"
void set_a(int new_a);

globals_a.c:

Code :

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

1
2
3
static int g_a;
int get_a() {return g_a};
void set_a(int a) {g_a = a;}

Encore mieux, définir la variable uniquement dans le module capable de le modifier (en static, d'ailleurs), et pas de setter possible.
interface.h:

Code :

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

1
2
// Only read-only
int get_interface();

interface.c:

Code :

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

1
2
3
static int g_interface;
int get_interface() {return g_interface};
void set_interface(int valeur) {g_interface = interface;}

[troumad]

Ce que vous dîtes va sans le sens de c qu'à fait imperio. Non ?

Je suis bien d'accord avec

leternel a raison pas de fichier extern.h

J'avais été surpris par ce .h !

J'ai aussi des constantes définies comme ça :

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
const gchar vd_add1[13][14][4]= /* vade retro */
{
    {"10","7","4","T","T","D","D","D*","D*","D*","D*","D*","D*","D*"},
    {"13","10","7","T","T","D","D","D","D*","D*","D*","D*","D*","D*"},
    {"16","13","10","4","T","T","D","D","D","D","D","D","D","D*"},
    {"19","16","13","7","4","T","T","D","D","D","D","D","D","D*"},
    {"20","19","16","10","7","4","T","T","D","D","D","D","D","D"},
    {"-","20","19","13","10","7","4","T","T","T","T","T","T","D"},
    {"-","-","20","16","13","10","7","4","T","T","T","T","T","D"},
    {"-","-","-","20","16","13","10","7","4","4","4","4","4","T"},
    {"-","-","-","-","20","16","13","10","7","7","7","7","7","T"},
    {"-","-","-","-","-","20","16","13","10","10","10","10","10","4"},
    {"-","-","-","-","-","-","20","16","13","13","13","13","13","7"},
    {"-","-","-","-","-","-","-","19","16","16","16","16","16","10"},
    {"-","-","-","-","-","-","-","20","19","19","19","19","19","13"}
};

Ce sont des variables déguisées. C'est moyen, mais mieux que le reste. Mais, est-ce modifiable en "#define" ça ?

[phi1981]

Une autre solution c'est de regrouper les paramètres dans une structure, et de passer un pointer vers cette structure qualifié const, comme ceci:

Code :

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

1
2
3
4
5
6
7
8
9
 
typedef struct mes_params_struct
{
   int niveau_vroumzeur;
   int temps_de_decollage;
   float index_zappy;
} mes_params;
 
void demagnitizer_le_vroumzeur (const mes_params *params, const char *fichier_vroumzeur);

La fonction demagnitizer le vroumzeur n'aura pas la possibilité de modifier la structure des paramètres.

En tout cas, même si ma solution ne te convient pas, par pitié pour les générations futures, n'utilise pas de globales... C'est pratiquement toujours une mauvaise idée, l'exception c'est généralement quand quelqu'un avant toi l'a déjà fait et que tu n'as pas la possibilité de réecrire le code.
Je pourrais passer une journée entière à donner des exemples vécus personnellement où une globale m'a compliqué la vie sans avantage clairement visible.