Pool mémoire

Bonjour,
Je vous propose un sujet sur lequel je me suis penché récemment et qui s'avère intéressant bien que simple.
Il s'agit de créer un pool mémoire. Qu'est-ce donc ?
C'est une large zone de mémoire qu'on alloue dans laquelle on va procéder nous-même aux allocations pour un type de donnée précis.
Il faut donc d'abord avoir un type de donnée que l'on va avoir à allouer plusieurs fois. Exemple :

Code:

typedef
struct
{
  int valeur;
}
Donnee;


Que faire précisément ?
- Allouer un gros bloc de mémoire
- Le préparer pour qu'il soit prêt à accueillir plusieurs objets de type 'Donnee'
- Construire une fonction qui y "alloue" un objet de type 'Donnee' et qui renvoie son adresse ou NULL s'il n'y a plus de place dans le pool
- Construire une fonction qui "libère" un objet
- Enfin, construire une fonction qui libère le bloc de mémoire
Bien entendu, on peut produire quelques variantes mais c'est l'idée générale.

Maintenant, à votre avis, en quoi est-ce utile ?

Ah, dommage... Ce sujet ne semble pas aussi intéressant/simple que je le pensais.

Pourquoi vous êtes ci rapide pour juger le problème le C/C++ permet de redéfinir les fonctions d'allocation/de libération de mémoire new et delete. Donc c'est faisable. J'avais un livre qui traitait cela en Turbo C++ mais j'ai oublié où est-ce que je l'ai caché.

Je ne demande pas de solution ! Je ne fais que proposer cela comme exercice.

Maintenant, à votre avis, en quoi est-ce utile ?

Bon à mon avis, ça sert comme une initiation à l'allocation dynamique de la mémoire. Ca peut se donner comme mini-projet: ré-implémentation des fonctions d'allocation ou désallocation de la mémoire.

non, Timon?

methodiX a écrit:Bon à mon avis, ça sert comme une initiation à l'allocation dynamique de la mémoire.
[...]
non, Timon?

En effet, mais heureusement, ça ne se limite pas qu'à ça !

De plus, on peut gagner la gestion personnalisée de la mémoire
Protéger ses propres zones, partage et swap de mémoire ...

methodiX a écrit:De plus, on peut gagner la gestion personnalisée de la mémoire

Oui, on y gagne par exemple lorsque l'on sait dès le départ combien de données maximum seront allouées à tout instant. Grâce au pool mémoire, on est alors certain que l'allocation réussira. Bien entendu, si on n'en a aucune idée, l'allocation réussira seulement tant que le pool ne sera pas plein.
De plus, il n'y a pas de risque de fragmentation puisque toutes les données ont dans le pool (en général) la même taille. On utilise donc cette zone mémoire au mieux.
Enfin, on profite aussi d'une allocation quasiment instantanée puisqu'on sait précisément (ou presque) où il y a de la place.

Salut Timon:
L'idée m'a beaucoup plu. Cependant, l'histoire de la fragmentation de la mémoire n'a pas été bien abordée. On sera toujours face à un problème de réorganisation de la mémoire, si on fait plusieurs allocations/désallocations de variables dynamiques dans le pool.

non?

Il ne peut pas y avoir fragmentation puisqu'on n'admet l'allocation que d'un type de donnée.
On pourrait considérer qu'il y a fragmentation si on cherche à allouer des tableaux. Or, le pool mémoire n'est pas adapté pour ça. Il me semble que l'on parle sinon de memory chunk.

Qu'appelles-tu "Type de donnée" ? Donner des exemples pour qu'on puisse parler le même langage.

nabiL a écrit:Qu'appelles-tu "Type de donnée" ? Donner des exemples pour qu'on puisse parler le même langage.

J'en ai déjà donné un.

Code:

typedef
struct
{
  int valeur;
}
Donnee;

Le pool mémoire ne contiendra que des objets Donnee.

Et le code ? Ou est-ce qu'il est dans tout cela ?

Quel code manianis?

Timon: int valeur ==> pour stocker quoi? une @mémoire? J'ai pas bien digéré l'histoire. Je suis un peu loin de l'informatique!

methodiX a écrit:Timon: int valeur ==> pour stocker quoi? une @mémoire? J'ai pas bien digéré l'histoire. Je suis un peu loin de l'informatique!

C'est un exemple.
J'aurais pu mettre autre chose. Par exemple, simplement :

Code:

typedef int Donnee;

voire indiquer que la donnée est d'un tout autre type !
Ce qu'est Donnee, on s'en fiche. C'est l'objet lui-même qui importe.
L'objectif est de donner au fur et à mesure des objets de ce type à l'appelant, tant que le pool mémoire le permet.