CRÉER DES TABLEAUX DE DONNÉES DE MANIÈRE DYNAMIQUE

Commentaire de patatalo le 30/11/2010 20:49:08 administrateur CS

salut,


Tu devrais pouvoir agrandir l'index sans changer l'emplacement en mémoire en reservant une partie plus grosse mais en commitant morceau par morceau.

Le heap étant pour moi une interface entre la memoire virtuelle et une allocation memoire malloc, les éléments de petite taille pourraient avoir une gestion d'allocation différente de ceux de grosse taille. Chaque petit objet < 16 octets seraient stockés dans une liste chainée.

--HEAD
| DATA1
->NODE1--
  DATA2 |
  NODEN<-
  DATAN

Je ne suis pas sur que cela puisse empêcher d'oublier de liberer un bloc mémoire devenu inutile dans le programme (leak). Windows libère la mémoire d'un process quoi qu'il en soit à la fermeture de ce process. Rien de gagné pour le système en lui-même.

@++

Commentaire de patatalo le 05/12/2010 01:07:18 administrateur CS

pas vraiment compris ce que tu racontes. Tu ne confondrait pas memoire virtuelle et memoire physique ?

Commentaire de patatalo le 05/12/2010 01:53:32 administrateur CS

ici, tu trouveras la fonction VirtualAlloc:
http://msdn.microsoft.com/en-us/library/aa366887%28VS.85%29.aspx

Si la mémoire avait dû être gérée par index comme les HINSTANCE et autres handles, je ne pense pas qu'ils aient eut besoin de l'ingeniosité de Toutenmasm ;-)

Commentaire de patatalo le 06/12/2010 23:02:17 administrateur CS

Evidement que c'est le système qui s'occupe de gerer les choses derrières les fonctions que tu utilises (heureusement non ?). Cela ne t'empêches certainement pas de faire ta propre sauce. D'ailleurs, les gestionnaires de heap n'ont pas tous les mêmes benchmark et les mêmes capacitées.

Je pense plutôt que tu travaille sur des sujets que tu ne maîtrises pas tout en voulant nous faire croire que oui. L'utilité de cette source pour toutes les raisons que tu avances est loin d'être prouvé.

Commentaire de patatalo le 09/12/2010 02:38:26 administrateur CS

Je me demandais comment ton truc pourrait fonctionner et peut-être est-ce là l'idée que tu avais:

pour empêcher les fuites de memoire, il faudrait que le programme soit découpé en morceau bien distinct. Chaque morceau disposerait de son propre tableau. Quand le programme saute d'une étape à l'autre, on sait que l'on peut liberer le tableau dans son ensemble.

Ca me paraît quand même assez chaud à mettre en place pour un logiciel digne de ce nom. De plus, ce que l'on gagnerait en sécurité, on le perdrait en besoin de traitement.

Pour finir, je dirais que le code qui gère le tableau ne devrais pas retourner des indexes à l'appelant mais le pointeur quand même afin d'eviter des appels trop fréquents au tableau. Le tableau ne servirait ainsi que de garde fou. ( C'est peut-être déjà comme cela que tu l'as prévu, je n'ai pas regardé le code car les .inc ne sont pas téléchargeables directement.) A ce propos, tu peux tout à fait faire un include "file.asm", ce n'est pas gênant pour l'assembleur.

@++

Commentaire de patatalo le 09/12/2010 17:14:14 administrateur CS

"Si patatalo veut faire "sa sauce" à la place de microsoft,rien ne l'empêche de faire un source.
Ce serait une bonne réponse."

Tu trouveras dans la source "livecd" un fichier qui s'appelle mmap.asm: c'est un début d'idée, le porter sur Windows serait très simple.

Commentaire de patatalo le 12/12/2010 12:11:46 administrateur CS

Si tu avais regardé le code, tu aurais vu qu'une fonction réalloc verifie avant de changer d'adresse, si il n'est pas possible de le faire sans.

Je n'ai pas la prétention de faire mieux que microsoft mais toi tu as celle de faciliter la gestion de la memoire. Je ne fais que transmettre des choses que j'ai réfléchies à l'avance...

Commentaire de ToutEnMasm le 12/12/2010 14:28:23

"Si tu avais regardé le code, tu aurais vu qu'une fonction réalloc verifie avant de changer d'adresse, si il n'est pas possible de le faire sans."
Voila,j'ai gagné 10 mn à regardé ton code et j'obtiens en plus un aveu,le changement d'adresse est nécessaire dans certains cas.
HeapReAlloc ne fait rien d'autre et surement mieux que toi (sans vouloir te vexer).

Commentaire de ToutEnMasm le 15/12/2010 18:37:44

Je n'ai pas trop le temps de "cogiter" là desus et HeapReAlloc me va bien.Merci quand même.
Ce qui peut être fait,si la chose t'interesse,ce sont des tests de rapidité sur le même type de fonctions que HeapReAlloc.Avec la heap ,avec globalrealloc..
Globalrealloc est donné plus rapide sur de gros blocs de mémoire et Heaprealloc plus rapide sur de petits blocs de mémoires,reste a savoir dans quels conditions et à vérifier l'assertion.

Commentaire de patatalo le 21/12/2010 01:11:19 administrateur CS

Il faudrait être un idiot pour croire que réalloc puisse toujours avoir le même pointeur. Cependant, il y aurait des solutions intermediaires: allouer une zone virtuelle plus grosse et allouer physiquement par petit morceaux à la demande. C'est ce que je t'ai expliqué plus haut mais tu as crié à l'impossibilité, or, ce que tu ne sais pas faire n'est pas forcement impossible.

Deuxièmement, le changement de pointeur est embêtant dans quels cas: Quand le pointeur est partagé par plusieurs fonctions ou threads. Il serait possible de faire les fonctions AllocForRealloc et Realloc2 qui contiendraient la gestion de la memoire virtuelle en plus.

Donc oui, je serais capable de la programmer et non, je ne l'ai pas encore fait. Cela ne veut pas dire que c'est impossible mais juste que je n'en ai pas eut encore besoin.

@++