Discussion :

[titux]

Hello, World

Alors voilà,
Je suis en train de coder une appli que j'aimerais par la suite publier, sans trop passer pour un Crado-codeur...
Seulement, j'ai une formation d'électronicien, pas de programmeur informatique.
J'ai appris à coder en C en Bts et j'ai approfondi en autodidacte ces 10 dernières années...

Pour mon appli, après avoir produit un 1er code totalement dégueu qui au final buggait,
j'ai lu une partie du bouquin "Coder Proprement", avant de repartir de 0 dans mon appli
en tentant de coller au mieux aux conseils de ce bouquin.

Mais voilà, je me demande comment gérer les variables globales.
Dans la 1è version de mon code, j'avais 9 globales déclarées en extern sur la quasi totalité de mes fichiers...

J'espère ne pas trop me tromper, en pensant que les globales c'est comme tout, c'est pas dégueu en soi, il n'y que des façons dégueues de les gérer.
Sauf que pour l'instant je sais comment BIEN les gérer.
Ce que je voudrais, c'est utiliser une globale, dont la portée se limite au fichier.c de ma libraire uniquement, et pratiquer un peu comme en C++, que le reste de l'appli n'ai que des accesseurs...


Concrètement l'exemple suivant est-il une bonne façon de gérer ma globale ?
main.c

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
 
#include "Librairie.h
 
int main(){
InitialisationAppli();
/*
.
.
*/
UtiliserChamp(); 
}
 
void InitialisationAppli(){
 
InitialisationLibrairie();
}

Libriaire.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
 
 
struct CONFIG {
char *champ;
};
 
typedef struct CONFIG Config;
 
 
Config Configuration;
 
/*
Prototypes...
*/

Librairie.c

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
 
#include <string.h>
 
#include "Librairie.h
 
void InitialisationLibrairie(){
 
DefinirChamp("Test");
}
 
void DefinirChamp(char *str){
 
strcpy(Configuration.champ, str);
}
 
void UtiliserChamp(){
printf("%s", Configuration.champ);
}

Merci

[ram-0000]

Dans librairie.h, un truc comme cela :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct CONFIG {
char *champ;
} Config;
 
 
 
/*
Prototypes...
*/
extern int SetConfiguration(...);   // parametres à définir (nom de fichier, ...), code de retour à définir (0=0K, ...)
 
// fonction pour acceder à ta structure
// la fonction retourne un pointeur sur structure constante, ainsi l'appelant ne peut pas modifier la configuration
extern const Config * GetConfiguration(void);

Dans ibrairie.c, un truc comme cela

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
 
#include "Librairie.h
 
// variable locale au fichier librairie.c
// les autres modules ne peuvent l'utiliser directement, il doivent passer par GetConfiguration()
static Config ma_config;
 
int SetConfiguration(...)
{
   // init de la variable à 0
   memset(&ma_config, 0, sizeof(ma_config));
 
   // positionnement des différents champs
   ...
 
}
 
const Config * GetConfiguration(void)
{
   return &ma_config;
}

Et maintenant, l'utilisation dans main.c (par exemple)

Code :

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

1
2
3
4
5
6
7
#include "Librairie.h
int main(void)
{
   SetConfiguration(...); // passer les bon parametres
 
   printf("champ=%s\n", GetConfiguration()->champ); // a supposer que champ soit vraiment une chaine de caractères mais c'est l'idée
}

[titux]

Super, merci ram-0000 pour ta réponse

[Bktero]

Je ne peux qu'être d'accord avec Raymond sur ce coup-là ! J'ai justement écrit un article où je conseille d'utiliser une telle technique : http://gradot.wordpress.com/2014/07/...globales-en-c/ Et on en a discuté sur Developpez : http://www.developpez.net/forums/d14...iliser-extern/

[ternel]

Juste une petite question.
Dans l'en-tête, le extern devant les fonctions est-il nécessaire? Je le croyais implicite sur les déclarations de fonctions.

[ram-0000]

Dans l'en-tête, le extern devant les fonctions est-il nécessaire? Je le croyais implicite sur les déclarations de fonctions.

Il est effectivement implicite (et donc facultatif) mais comme disait mon responsable qualité, "ce qui va sans dire va mieux en le disant" .

Et puis cela permet au débutant qui rentrera dans le code plus tard pour le modifier de ne pas se prendre la tête en se demandant "quel est le comportement implicite ?"

[Bktero]

A ma connaissance, c'est le cas

Je m'en sers des fois quand j'importe à l'arrache (et donc normalement de manière temporaire ) des fonctions sans passer par un fichier d'en-tête, pour insister que sur le faitque la fonction est définie dans une autre unité de compilation.

[ternel]

Ca me rassure. C'est pour le bien de l'explicitation, ce qui me semble en effet un bon choix.
C'est juste tellement rare de le voir que j'ai été surpris.

Merci!

[Obsidian]

Il est effectivement implicite (et donc facultatif) mais comme disait mon responsable qualité, "ce qui va sans dire va mieux en le disant" .
Et puis cela permet au débutant qui rentrera dans le code plus tard pour le modifier de ne pas se prendre la tête en se demandant "quel est le comportement implicite ?"

Mouais. Moi, par contre, je ne suis pas fan du tout de ce genre d'approche.

Certes, le C est un langage très permissif et c'est très bien comme cela. Chacun est libre d'adopter le style qui lui convient le mieux pourvu qu'il soit capable de le justifier et qu'il s'y tienne, même si de nombreux extrémistes voient en cela une manière d'éprouver le pécheur et une bonne occasion de vilipender l'âme perdue qui a mis une accolade sous sa fonction au lieu de la mettre à droite (ou vice versa) pour la remettre dans le droit chemin. Malgré cela, je préfère adopter l'approche « mathématique » dans laquelle on écrit une expression sous forme irréductible et, surtout, où l'on évite autant que possible de rédiger des expressions qui n'ont aucun effet.

Par exemple, je suis contre le fait d'ajouter systématiquement des parenthèses à sizeof là où la grammaire n'en réclame pas, même si c'est le seul mot-clé réservé du langage C qui se comporte comme une fonction. De même, j'évite les extern sur les prototypes de fonction. Ils sont nécessaires pour les variables car le fait de déclarer celle-ci vaut instanciation. Ça ne peut jamais arriver avec une fonction sans le corps et il n'y a pas d'ambiguïté.

De fait, je préfère m'en tenir à la forme canonique originale car c'est surtout en lisant le code des autres qu'on apprend et que l'on retient le plus.

[ternel]

D'où ma surprise, en effet.

[ram-0000]

Mouais. Moi, par contre, je ne suis pas fan du tout de ce genre d'approche.

Chacun est libre d'adopter le style qui lui convient le mieux pourvu qu'il soit capable de le justifier et qu'il s'y tienne

Et je m'y tiens. Les gouts et les couleurs... mais ton point de vue est tout autant respectable, je ne suis pas un extrémiste.

[Bktero]

J'ai longtemps été partisan de ton approche Obsidian. D'ailleurs, j'utilise encore beaucoup cette façon de faire. J'ai néanmoins remarqué, et quelques lectures m'ont confirmé cela, qu'il est parfois préférable d'écrire des choses "inutiles" (en explicitant de l'implicite) car cela peut être plus simple pour ceux qui connaissent moins le langage de ne pas se poser de questions existentielles ou risquer de les induire en erreur (ou même pour soit dans quelques mois ou années si on pratique un peu moins d'ici là ^^). Je pense par exemple au parenthésage de certaines opérations comme int i = 12 << 3 + 6 | 7;. La personne A qui connait bien le C (ou plutôt qui vient de lire les règles de priorité) pourra trouver la valeur de i sans problème ; la personne B qui code très peu en C en sera incapable et des parenthèses faciliteront grandement la lecture. On pourra dire que cela ne force pas les gens à apprendre pleinement le langage mais quand, dans une entreprise, plusieurs langages cohabitent, on gagne du temps (et donc de l'argent).