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

Version imprimable

26/03/2009, 15h22
Odulo

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

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
26/03/2009, 15h35
Médinoc

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

Citation:

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.
26/03/2009, 15h54
Odulo

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.
26/03/2009, 16h11
pfeuh

Salut

Citation:

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
26/03/2009, 16h21
Odulo

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

Merci à vous
26/03/2009, 17h30
Médinoc

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).
27/03/2009, 11h49
Odulo

ok, j'ai opté pour la solution

Code:

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.

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

Code:

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:

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:

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!

27/03/2009, 13h31
Emmanuel Delahaye

Citation:

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.

Citation:

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).
27/03/2009, 13h33
Emmanuel Delahaye

Citation:

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/
27/03/2009, 14h08
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 ?
27/03/2009, 14h12
Emmanuel Delahaye

Citation:

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).
27/03/2009, 14h24
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

Code:

typedef struct parserConfig_s parserConfig_t;

et

Code:

struct parserConfig_s;

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

1 2 3 4 5 6 struct parserConfig_s { char cListDelimiter; char cEndOfLineDelimiter; char cAssignmentSymbol; };
?
27/03/2009, 14h31
Emmanuel Delahaye

Citation:

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.
27/03/2009, 14h34
Odulo

ok merci pour toutes ces informations, j'aurais bien aimé qu'il y ait une petite nuance entre les deux (j'aime bien les petites subtilités) :D
27/03/2009, 14h37
Emmanuel Delahaye

Citation:

Envoyé par Odulo

ok merci pour toutes ces informations, j'aurais bien aimé qu'il y ait une petite nuance entre les deux (j'aime bien les petites subtilités) :D

Le typedef requiert la définition préalable. Le struct, non. Pour tout ce qui est public et pour cette raison, je préfère le typedef.