[LIB] librairie de cache en C ?

Citation:

---

Ca facilite beaucoup l'accès à ces données plutôt qu'un tableau de void*.

---

L'accès est facilité, mais tu dois avoir un nombre de strutures incroyable... si je ne me trompe pas, ca donne quelque chose du genre

Code:

---

1 2 3 4 5

(les nombres choisis sont des exemples) Nombre de types différents existants : 3 (int, float, char*) Nombre de colones max d'une requète : 5   Nombre de structures possibles : 3^1 + 3^2 + 3^3 + 3^4 + 3^5 !!

---

Citation:

---

Et puis comment tu parcours un tableau de void* ? je doute que l'accès au 6ème champ (par exemple) se fasse par "champ[5]"...

---

Si si, bien sûr, comme pour un tableau de n'importe quel type. Seulement, il va falloir caster ton void* en un type concret (int*, float*, ...) pour pouvoir l'utiliser. Il te faut donc des infos en plus, stockées dans ton resultset, pour savoir de quel type est chaque colone.


Par exemple

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

enum type { entier, flottant, chaine };   struct resultset { int nb_colones; type* types_colones; // tableau des types contenus void** contenu_colones; // tableau des contenus eux-même (void*) };

---

Mais j'imagine que tu as déjà un code qui fonctionne pour tout cela. Mais c'est vrai que pour mettre en cache ces resultset différents, en programmation non OO, je ne vois pas de solution évidente, à part ce type de cast peu élégant.

Peut-être que quelqu'un peut donner son avis la dessus ?

Désolé mais on a du mal se comprendre, je n'ai pas un nombre hallucinant de structures différentes, juste autant que de resultset définis dans les procédures stockées (gdb sybase).

Exemple dans une proc stockée j'ai :

Code:

---

1 2 3

select codeHotel, numResa, date, numJour from #resa

---

Je stockerais chaque ligne dans une structure

Code:

---

1 2 3 4 5 6 7

typedef struct { char codeHotel[4];; char numResa[12]; char date[10]; short numJour; } Resa

---

et la totalité du resultset dans un tableau de cette structure.

Si jamais le resultset change, je dois changer la structure bien sûr.


Pour ce qui est de ta solution, elle est intéressante, puisqu'elle me permet de n'avoir qu'une seule structure pour tous les resultset, mais l'utilisation me paraît assez fastidieuse, à moins de développer une couche englobant l'implémentation de ce système...

Peux-tu développer un peu plus l'accès à des éléments d'un tableau de void* ?

Merci

Ahhhhhh :D
D'accord, je ne savais pas que tu disposais d'un nombre de requètes bien fixes. A ce moment là, en effet plus de problème, sauf pour le stockage en cache, ou je ne vois pas comment faire cohabiter ces structures au sein d'une même table de hachage.

Pour ce qui est du tableau de void*, l'accès se fait comme dans un tableau normal: tab[5]. Mais tu vas obtenir un void* qu'il faut ensuite caster comme il faut :arrow: il faut donc connaitre le type exact de ce qui se cache derrière, par exemple avec une structure "header" qui indique ce que contiennent tes colones.

Mais quitte à avoir un "selecteur" pour retrouver le type de chaque colone, autant finalement utiliser une union. Par exemple, en modifiant le code du post précédent:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

// types utilisables enum type { entier, flottant, chaine };   // en tête de résultat : les colones typedef struct { int nb_colones; // nombre de colones type* types_colones; // leur type } header;     // une case de ton tableau final (par ex. ligne 3 colone 2) typedef union { int entier; float flottant; char* chaine; } case;     // la totalité des resultats typedef struct { header entete; int nb_resultsets; // nombre de lignes case** resultsets; // tableau représentant les lignes (ligne = case*) } resultat;

---

et maintenant l'utilisation
par exemple si on a fait une requete de type {int, float, char*}

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

resultat r;   r.entete.nb_colones = 3; // int, float, et char* r.entete.types_colones = malloc( r.entete.nb_colones * sizeof(type) ); r.entete.types_colones[0] = entier; r.entete.types_colones[1] = flottant; r.entete.types_colones[2] = chaine;   // on va dire que la requete a retourné 15 lignes r.resultsets = malloc( 15 * sizeof(case*) ); for (int i=0; i<15; ++i) r.resultsets[i] = malloc( r.entete.nb_colones * sizeof(case) );   r.resultsets[0][0].entier = 5; r.resultsets[0][1].flottant = 3.567; r.resultsets[0][2].chaine = ....;   // pour une autre requete qui retourne {char*, int} tu pourrais faire: r.resultsets[0][0].chaine = ...; r.resultsets[0][1].entier = 3; // mais avec un header qui reflete bien cette structure !

---

Pour les récuperer, il faut simplement tester ce qui se trouve dans le header:

Code:

---

1 2	if (r.entete.types_colones[0] == entier) printf("%d\n", r.resultsets[i][0].entier);

---

Voilà, c'était un début d'explication, pas forcément très clair :oops:, mais c'est un moyen comme un autre de stocker toutes tes requetes dans la même structure. Et il faut bien sûr penser a libérer la mémoire allouée :)

Voilà, avec ça pas de problème pour les stocker dans ta table de hachage. Mais quelqu'un a peut-être une autre idée pour utiliser ta méthode courante, avec plusieurs strcture différentes ?

Si si c'est très clair !! :) Merci pour cette solution intéressante, je vais réfléchir à son intégration.

En fait là tu n'utilises finalement pas de tableau de void*, la question que je me posait quant à l'utilisation d'un void**, c'est l'accès au données. En effet tu peux faire en sorte de savoir que le 3ème élément du tableau est un type char ou int (peu importe) et donc le caster en conséquence.
Mais pour y accéder ça me paraît plus hard avec "element[2]" car element[0] peut-être un char[12] et element [1] peut-être un int, donc un taille différente !! Ya une solution à ce genre de problème ?

Mmmm, si tu as un tableau de void*, tu stockes dedans uniquement des pointeurs. Donc des pointeurs sur int, sur char (pour les chaines), sur float .... A toi de caster ton void* en int*, char*, .... en fonction. Par contre ça implique une allocation dynamique systematique, ce qui n'est vraiment pas top niveau performances (*).

Pour éviter cette allocation dynamique, en stockant les types POD directement dans le tableau, je pense qu'il faut passer par une union (comme dans le code du post précédent).

Après, il est même possible de faire une union

Code:

---

1 2 3 4 5 6

union { int entier; float flottant; char chaine[32]; };

---

mais rappelle-toi que l'union va occuper la place de l'élément le plus gros (logique ...). Donc la elle occupera 32 octets, pour chaque case du tableau, même si il n'y a qu'un int stocké dedans :? C'est pas top ....

D'où le char* pour gérer les chaines de caractère dans l'union. Ton union (int,float,char*) ne prendra que 4 octets, donc pas de perte apparente. Et les chaines seront le seul type géré par allocation dynamique dans tes resultset.

--

(*) : <mode déconsillé, pas beau, non portable, et illisible> :nono:
Dans le cas d'un tableau de void*, tu "pourrais" te passer de l'allocation dynamique pour les int et les float. Sur une architecture 32 bits classique ils font tous les deux 4 octets, comme un pointeur. Donc il serait possible de les stocker dans le void*, et des les récuperer tels quels. Mais de jamais (!!!) s'en servir comme pointeur. Enfin de toute façon il ne faut pas le faire :)
</mode déconsillé, pas beau, non portable, et illisible>

Très instructif tout ça, merci !!

J'espère que j'ai pas raconté trop de bétises alors ....
Mais je me suis relu, normalement ça va :)

Ca serai sympa d'avoir un autre avis sur la manière dont tu pourrais procéder pour stocker tes resultats dans ta table de hachage... Pour l'instant, je ne vois qu'un changement de structure :arrow: 1 seule et même structure pour stocker tous les types de résulats.... Il y a peut-être une autre solution...

Mais c'est vrai que l'avantage de celle-ci, si tu découpes bien ton architecture de manière modulaire, c'est qu'il sera facile de rajouter des requètes, puisqu'il faut simplement créer une nouvelle instance de ta structure, avec le bon header, et elle pourra s'ajouter aux autres de manière transparente.

En effet ce serait pratique.