utilisation d'une variable globale dans une librairie, quels sont les risques ?

**Odulo** · 26/03/2009, 14h22

Bonjour,

Je me pose une question sur les risques pouvant découler de l'utilisation d'une variable globale dans une librairie.

J'écris une librairie pour faire du parsing. Je souhaiterai que les modules qui vont utiliser cette librairie aient le moins de chose à gérer possible.

Par exemple, j'ai une structure de configuration contenant les délimiteurs de liste, de fin de ligne, etc. Je n'ai pas envie que le module utilisant la lib doive s'allouer la structure et la passer à chaque appel à la librairie.

J'ai donc pensé à déclarer la structure en globale dans la librairie, de cette manière plus besoin de s'en occuper puisqu'elle sera gérée dans la lib. Je me pose tout de même des questions sur les risques potentiels, je pense à des accès multiples à la librairies.

Je ne pense pas que cela puisse poser des problèmes si ces accès se font depuis des processus différents, peut être que je me trompe. Mais si ce sont des threads d'un même processus qui veulent parser un fichier avec des configurations différentes ?

Par avance merci

**Médinoc** · 26/03/2009, 14h35

Tu ne t'es pas trompé dans ton évaluation des risques. Par contre, je reviendrais là-dessus:

Je n'ai pas envie que le module utilisant la lib doive s'allouer la structure et la passer à chaque appel à la librairie.

Le module "utilisateur" n'a pas à allouer la structure, c'est à la lib de le faire (et de retourner un pointeur, de préférence un pointeur opaque).

Ainsi, tout ce qu'il y a à trimbaler dans le code utilisateur, c'est le pointeur en question.

**Odulo** · 26/03/2009, 14h54

Oui effectivement, l'utilisateur peut se passer de l'allocation.

J'ai raison dans le cas de threads ou simplement des processus ? Si en multi processus cela peut fonctionner, ça ne me gêne pas. Peu de change que la lib soit utilisée avec des threads dans un même process, au pire je peux poser un mutex.

Je ne sais pas quelle est la solution la plus propre, personnellement ça me gêne de traîner ce pointeur, l'utilisateur ne sait pas vraiment à quoi il sert, ce qu'il se passe avec.

**pfeuh** · 26/03/2009, 15h11

Salut

Envoyé par Odulo

Je ne sais pas quelle est la solution la plus propre, personnellement ça me gêne de traîner ce pointeur, l'utilisateur ne sait pas vraiment à quoi il sert, ce qu'il se passe avec.

Quand tu ouvres un fichier avec fopen, la fonction te retourne un pointeur vers une structure de type FILE. Ca ne gène absolument personne de recevoir ce pointeur sans savoir ce qu'il y a dedans. Ca permet aussi aussi d'ouvrir plusieurs fichiers à la fois et de s'y retrouver malgré tout, même avec les threads.

A+

Pfeuh

**Odulo** · 26/03/2009, 15h21

Oui effectivement pfeuh, je vais donc procéder ainsi avec un void * comme le suggère Médinoc.

Merci à vous

**Médinoc** · 26/03/2009, 16h30

Je n'ai jamais dit void*, j'ai dit pointeur opaque, ça n'est pas la même chose.

Un pointeur opaque, c'est un pointeur vers une structure qui est déclarée mais pas définie (en clair, sa définition se trouve dans les fichiers d'en-tête internes à ta bibliothèque, mais pas dans celui que tu livres avec).

**Odulo** · 27/03/2009, 10h49

ok, j'ai opté pour la solution

Code :

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

typedef struct parserConfig_s parserConfig_t;

dans l'api et ma structure parserConfig_s est définie en locale, il me semble que cette méthode est pas mal et qu'elle empêche l'utilisateur de s'amuser à essayer de jouer avec les champs de ma structure.

**Médinoc** · 27/03/2009, 11h09

Ce typedef ne change pas grand-chose. L'essentiel, c'est que l'utilisateur ne voie pas les champs.
Exemple:

Code C :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/* OduloLib.h */
 
/*
Créé par Odulo, sous license ___
*/
 
struct parserConfig_s;
/*Si la bibliothèque est une DLL, mettre les defines appropriés ici.*/
 
/* Fonction d'initialisation d'un parser
Retour: pointeur du parser, à utiliser pour les autres fonctions. */
struct parserConfig_s * InitParser(
 int unParametre, /*Un paramètre et sa documentation*/
 int unAutreParametre /*idem*/
 );

Code C :

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

1
2
3
4
5
6
7
8
/* OduloLibInterne.h */
 
struct parserConfig_s
{
	/*Le vrai contenu de la structure*/
};
 
/*Déclarations des fonctions internes à la bibliothèques*/

Code C :

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

1
2
3
4
5
6
7
8
/* OduloLib1.c */
#include "OduloLib.h"
#include "OduloLibInterne.h"
 
struct parserConfig_s * InitParser(int unParametre, int unAutreParametre)
{
	/* code de la fonction */
}

Ainsi, ton code utilisateur n'ayant accès qu'au .lib et au fichier fourni avec, il ne pourra pas voir la définition de la structure!

**Emmanuel Delahaye** · 27/03/2009, 12h31

Envoyé par Odulo

Je me pose une question sur les risques pouvant découler de l'utilisation d'une variable globale dans une librairie.

J'écris une librairie pour faire du parsing. Je souhaiterai que les modules qui vont utiliser cette librairie aient le moins de chose à gérer possible.

Par exemple, j'ai une structure de configuration contenant les délimiteurs de liste, de fin de ligne, etc. Je n'ai pas envie que le module utilisant la lib doive s'allouer la structure et la passer à chaque appel à la librairie.

J'ai donc pensé à déclarer la structure en globale dans la librairie, de cette manière plus besoin de s'en occuper puisqu'elle sera gérée dans la lib. Je me pose tout de même des questions sur les risques potentiels, je pense à des accès multiples à la librairies.

Je ne pense pas que cela puisse poser des problèmes si ces accès se font depuis des processus différents, peut être que je me trompe.

Le fait qu'il y a ait des globales signifie que le code ne peut être instancié. C'est dommage, mais si ce n'est pas génant, c'est toi qui voit.

Si ces variables globales sont à lecture seules (sauf config au démarrage), c'est sans risque pour la suite, si ce n'est que la configuration est unique.

Mais si ce sont des threads d'un même processus qui veulent parser un fichier avec des configurations différentes ?

Ca, par contre, c'est un vrai problème. La configuration est unique pour un processus donné (et tous les threads qui vont avec).

**Emmanuel Delahaye** · 27/03/2009, 12h33

Envoyé par Médinoc

Ce typedef ne change pas grand-chose.

Bah, si, ça permet d'être vraiment opaque (plus qu'en C++ en tout cas).

http://emmanuel-delahaye.developpez....its-donnees-c/

**Odulo** · 27/03/2009, 13h08

Justement j'ai une question : est ce que passer par le typedef revient au même qu'utiliser une définition incomplète de la structure.

Cela m'a l'air identique mais n'y a-t-il pas une petite subtilité derrière ?

**Emmanuel Delahaye** · 27/03/2009, 13h12

Envoyé par Odulo

Justement j'ai une question : est ce que passer par le typedef revient au même qu'utiliser une définition incomplète de la structure.

Cela m'a l'air identique mais n'y a-t-il pas une petite subtilité derrière ?

Ça dépend comment tu l'utilises.

Si c'est pour remplacer la structure, ça ne change rien à part la simplification de la syntaxe.

Si tu le fais en séparant l'interface de l'implémentation (comme expliqué dans l'article TAD déjà cité), tu obtiens un véritable objet opaque dont les champs sont définitivement invisibles à l'utilisateur (sauf via une fonction dédiée).

**Odulo** · 27/03/2009, 13h24

Je me suis peut être mal exprimé (ou que j'ai mal compris la réponse ! ), je ne parle pas d'un simple typedef sur une structure mais d'un typedef pour "privatiser" la strucutre, y a-t-il une différence entre ça

Code :

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

typedef struct parserConfig_s parserConfig_t;

et

Code :

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

struct parserConfig_s;

si placé dans l'API et qu'en interne j'ai

Code :

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

1
2
3
4
5
6
struct parserConfig_s
{
	char cListDelimiter;
	char cEndOfLineDelimiter;
	char cAssignmentSymbol;
};

?

**Emmanuel Delahaye** · 27/03/2009, 13h31

Envoyé par Odulo

Je me suis peut être mal exprimé (ou que j'ai mal compris la réponse ! ), je ne parle pas d'un simple typedef sur une structure mais d'un typedef pour "privatiser" la strucutre, y a-t-il une différence entre <...>

A part la simplification de la syntaxe (plus besoin de 'struct'), non.