Discussion :

[|PaRa-BoL]

Bonjour,

Petite question :

J'ai une structure que j'utilise très fréquemment (dans une centaine de fonctions). Actuellement je l'a passe en paramètre à chaque fois et ça commence à devenir fastidieux à maintenir.

J'ai toujours évité les globales, mais dans ce genre de cas je me pose la question. A quel niveau cela à t il un impacte (a par pourrir mon namespace) ?

Ma structure :

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
 
typedef struct _acetables
{
	HTBL **hLogin;
	HTBL **hSessid;
	HTBL **hLusers;
	HTBL **hCallback;
 
	HTBL **hPubid;
 
	struct srvconfig *srv;
	struct USERS *uHead;
 
	struct _ticks_callback *timers;
 
	unsigned int nConnected;
 
	struct _ace_plugins *plugins;
 
	struct _extend *properties;
} acetables;

Merci

[Médinoc]

Eh bien, ça peut surtout te pourrir la réentrance, la thread-safety, et bien sûr, ça te limite à un seul exemplaire de la structure...

En clair, pour une bibliothèque, c'est à bannir.

[salseropom]

Salut, pour ma part, je passerais ta structure en paramètre (attention, tu passes un pointeur vers cette structure bien entendu !). J'essaye tant que possible d'éviter les globales car je trouve que la relecture du code est plus aisée et cela peut éviter de future bêtises (un collègue reprend ton code, ton code est partagé entre plusieurs développeurs etc...).

Je ne vois pas en quoi cela gêne de passer un pointeur vers une structure en paramètre à une centaine de fonctions...

Si tu as une énorme structure qui contient énormément de champs, en quoi cela est-il fastidieux à maintenir ? Car dans le fond, le prototype de tes fonctions reste inchangé : tu ne fais que rajouté des champs à ta structure donc tu ne modifies "que" du fichier .c et ton fichier .h qui contiennent le code et la déclaration de ta structure avec toutes les fonctions d'accès à cette structure (création, copie, duplication, destruction, get, set etc...)

Bref, je ne serais absolument pas gêné de passer cette structure en paramètre à une centaine de fonctions.

[|PaRa-BoL]

Merci pour vos réponses.

En revanche concernant le fait que ce soit thread-safe il y a quelque chose qui m'échappe.

Par exemple dans ma structure je fait référence à plusieurs tables de hashage (ou chainlist peu importe).

imaginons une fonction prenant comme paramètre ma structure. Cette fonction va ensuite modifier une des tables de hashage pointée par ma structure. En quoi cela est thread-safe à ce niveau si 2 thread font appelle à cette fonction ? C'est juste l'accès à la structure qui va être "safe" ?

Merci

[Gruik]

Salut,

+1 avec les autres, la structure en paramètre est LA bonne solution. (j'appelle ça un "contexte")

Le fait de pas avoir de globale ne rend pas obligatoire l'utilisation du meme contexte, ce qui permet d'avoir des morceaux du soft indépendants qui utilisent leur propre contexte initialisé/paramétré comme ils le veulent sans que les autres puissent le modifier, idem pour des threads qui pourraient posséder leur contexte sans pourrir les autres.
Biensur tu veux pouvoir avoir des threads qui accedent au meme contexte auquel cas, il te faudra utiliser les mutex & co, de la meme façon que si t'avais une globale.
Mais avec un contexte, la "globalité" n'est pas obligatoire

Il y a plein de problèmes dans les bibliothèques C et Unix qui auraient pu être évités si il n'y avait pas eu de paramétrage global obligatoire (par exemples les locales, l'umask, le timezone..) au profit d'une structure intialisée et gérée par l'appelant.

[souviron34]

Il y a plein de problèmes dans les bibliothèques C et Unix qui auraient pu être évités si il n'y avait pas eu de paramétrage global obligatoire (par exemples les locales, l'umask, le timezone..) au profit d'une structure intialisée et gérée par l'appelant.

les mécanismes fournissent uniquement une valeur par défaut...

Un setenv dans un programme ne touche en rien le reste !!

Je ne vois pas en quoi cela est "global" ??

[Gruik]

Bein si t'as une partie de soft qui modifie la locale et que le reste du soft est prévu pour marcher dans une autre locale, bein ça marche plus comme il faut.
Heureusement, les fonctions comme setlocale() et umask() retournent la valeur précédente ce qui permet de repositionner à la locale précédente.
Mais justement lorsqu'il y a des threads, le thread peut s'interrompre entre le moment où on modifie la locale et le moment où on la repositionne..

Le coup de setenv, ça s'applique qu'a la timezone, je disais juste qu'il aurait été préférable d'avoir les fonctions localtime() etc qui prennent en paramètre une structure de contexte qui contient au moins la timezone, au lieu d'utiliser la variable d'environnement TZ

[souviron34]

ok, mais c'est simplement (voir les multiples discussions à ce sujet) parce que les threads ne sont pas "unix-naturels". C'est arrivé sur les unixoides (en tous cas les utilisations massives) par le biais de gens venant du monde M$, qui ne savait pas gérer vraiment plusieurs processus en //.


Et en ce qui concerne les bibliothèques ré-entrantes, ça se gère.. Avec des tableaux locaux..

[Gruik]

Et en ce qui concerne les bibliothèques ré-entrantes, ça se gère.. Avec des tableaux locaux..

C'est à dire?

[souviron34]

des tableaux globaux statiques dans le module ré-entrant, qui garde à chaque coup la variable et des pointeurs idoines...

Mais il est évident qu'un "contexte" est plus facile à manipuler.

Mais cette notion existe aussi en C et sous unixoides...

[Médinoc]

Euh... Si c'est global statique, comment est-que que ça peut être réentrant?
Il doit forcément il avoir un contexte venant de l'extérieur, même s'il ne s'agit que d'un simple descripteur...

[souviron34]

Comme ceci

strtok_r

char *strtok_r (char *s, const char *delim, char **ptrptr);

[Médinoc]

Ben, y'a rien de global statique ici, justement...

Il y a un contexte fourni par l'appelant.