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 ?

[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.

[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 ?

[Médinoc]

Je ne pense pas que ce soit remplaçable par du #define, mais de la variable globale const, c'est acceptable (données d'initialisation).

Toutefois, il n'y a pas vraiment de raison de la rendre globale à tout le projet quand on peut limiter sa portée à une unité de compilation et n'exporter que la fonction qui la lit.

[ternel]

je vais me faire gronder, je le sens

#define n'est pas du C, c'est du préprocesseur C.
Quoi que fasse #define, ca produit du C, qui est incapable d'avoir une variable pas complêtement constante.

Par contre, il est possible d'avoir une fonction retournant une copie d'une variable globale.

L'idée, c'est de ma solution, c'est d'avoir une variable "globale" visible uniquement dans une seule unité de compilation, et copiable depuis n'importe où (pour peu qu'on inclue le bon header).
C'est la seule façon que je connaisse d'avoir une garantie sur l'inviolabilité.

C'est d'ailleurs comme cela que fonctionne srand() + rand(): on sait qu'il y a une seed, mais on ne sait pas du tout s'il y a une ou plusieurs variables globale derrière.

[imperio]

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

Je suis bien d'accord avec
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 ?

Je pense que oui, même si ça fait un define pas franchement très beau à lire, encore une fois tu pourrais. Par-contre là, je pense qu'il vaudrait mieux faire autrement. En deux temps par exemple : tu déclares des const char** puis après tu crées un const char*** qui pointe sur ces char**.

Code :

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

1
2
3
4
const gchar ligne1[14][4] = {"10","7","4","T","T","D","D","D*","D*","D*","D*","D*","D*","D*"};
const gchar ligne2[14][4] = {"10","7","4","T","T","D","D","D*","D*","D*","D*","D*","D*","D*"};
 
const gchar vd_add1[13][14][4] = {ligne1, ligne2};

Je pense que c'est grandement améliorable mais pour la visibilité je trouve ça déjà un peu mieux. Après ce n'est qu'un avis personnel.

[troumad]

Je pense que oui, même si ça fait un define pas franchement très beau à lire, encore une fois tu pourrais. Par-contre là, je pense qu'il vaudrait mieux faire autrement. En deux temps par exemple : tu déclares des const char** puis après tu crées un const char*** qui pointe sur ces char**.

Je ne vois pas de différence entre ta méthode et la mienne si ce n'est qu'il y a un intermédiaire de plus dans la tienne.

[ternel]

Dans la méthode d'império, les lignes sont nommées, ce qui permet de leur donner une signification explicite.

[Bktero]

Il y a un étape intermédiaire entre "je passe tout en paramètres" et "je mets tout en globales" ! Tu as le droit depuis des fonctions qui en ont besoin d'accéder à un modèle de données. Tu accèdes à ton modèle de données avec des getters et setters. Dans les unités de compilation où tu souhaites lire et écrire dans le modèle, tu inclues un header complet ; dans celles où ne souhaites que lire, tu inclues un header ne contenant que les getters (éventuellement en rajoutant les const nécessaires supplémentaires, voire même qui rendent des copies).

[troumad]

Je ne mets en globale que des variables d'environnement. Des données qui peuvent être considérées constantes car elles ne doivent pas être modifiées pendant l'exécution du programme, mais qui ne sont pas connues lorsque le programme se fait.
Ce sont des données qu'on peut compléter ou modifier en rajoutant ou modifiant des fichiers de configuration.

Sinon, tout ce qui est gestion des fenêtres et autres variables modifiées ou modifiables pendant le cours normal du programme, ce ne seront pas des variables globales. Je pense même que c'est infaisable vu la structure du programme.

[Bktero]

La façon dont les données sont obtenues ne modifient pas fondamentalement la manière de s'en servir (à mon avis). Si je prend par exemple la taille de la fenêtre principale, les modules ayant besoin de cette dimension la demande au modèles de données (le modèle graphique ici, si tu as plusieurs modèles). La manière dont le modèle se procure cette donnée (lecture dans un fichier, paramètre de la ligne de commande, etc.) ne change rien. Cela rend homogène ton programme car tu utilises une technique unique dans tous les modules pour récupérer les informations nécessaires au bon fonctionnement de l'application.