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

cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 30 nov. 2010 à 20:49
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 - 21 déc. 2010 à 17:32
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/52526-creer-des-tableaux-de-donnees-de-maniere-dynamique

cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
21 déc. 2010 à 17:32
Pour les allocations locales, il faut des petits blocs car sinon la fonction est obligée de passer par une allocation globale.

L'allocation globale est plus lente car elle doit faire appel au système plutôt que de rester dans son processus.

Je s
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
21 déc. 2010 à 01:11
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.

@++
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
21 déc. 2010 à 00:22
mmap.realloc:;(MMAP*,*,CB):CF&EAX=SIZE,!CF
LBEG
mov ebx,__parm(1)
mov eax,__parm(2)
xor edx,edx
mov esi,[ebx+MMAP.pdir]
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
mov edx,[esi+ecx*8+4]
lea edi,[esi+ecx*8+4]
.1; tant que ccb < cbreq
cmp edx,__parm(3)
mov eax,__parm(2)
jb .3
je .4
.2;recherche du bloc suivant
mov esi,[ebx+MMAP.pdir]
add eax,edx
mov ecx,[ebx+MMAP.cdir]
call mmap.getnode
jb .5
.21;allocation du bloc suivant
btr pd[esi+ecx*8+4],BLOCLOCK
jnb .5
.22;liberation du bloc suivant
add edx,[esi+ecx*8+4]
mov pd[esi+ecx*8],0
mov pd[esi+ecx*8+4],2
jmp .1
.3;coupe le bloc.
mov eax,__parm(3)
sub edx,__parm(3)
add eax,__parm(2)
call mmap.allocnode
mov eax,edx
mov edx,__parm(3)
jnb .4
add edx,eax
.4;met a jour la node.
mov [edi],edx
mov __eax,edx
clc
LEND
ret
.5
mov __eax,edx
stc
LEND
ret

Cette fonction réalloc ne change jamais le pointeur, elle préfère ressortir en echec. A l'utilisateur de réallouer une autre zone et de copier la précedente. J'aurais pu automatiser mais je n'ai jamais utilisé ni même testé cette fonction. Par contre, on y pense pas forcement mais un réalloc d'une zone plus petite libèrera la partie en trop.

Vu que ça semblait te tenir à coeur de la voir, la voilà...
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
15 déc. 2010 à 18:37
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.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
15 déc. 2010 à 12:36
Si tu avais regardé le source, tu aurais vu que le code n'est plus mis à jour. Ma version est ok. Pour finir, ce n'est pas une question de mieux ou de moins bien, mais de choix...

Si tu nous exposais les tiens, il y aurait peut-être matière à cogiter...
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
12 déc. 2010 à 14:28
"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).
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
12 déc. 2010 à 12:17
Et puis au lieu de me parler de "Microsoft", parle moi plutôt de Russinovich et des programmeurs qui existent réellement.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
12 déc. 2010 à 12:11
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...
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
10 déc. 2010 à 17:31
Si on suit tes dires , tu es capable de créer le même type de fonction que HeapReAlloc ,remplissant le même rôle, et ceci sans que la fonction décale les adresses.
J'attends cette fonction,et non pas une autre,ou du baratin.
Ta prétention est,je fais mieux que microsoft.Prouve le.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
9 déc. 2010 à 17:14
"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.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
9 déc. 2010 à 03:56
Il y a une autre solution qui est utilisée dans le kernel Windows mais pas pour cette raison je crois. Il faudrait associer des tags aux allocations, ce qui permettrait de savoir à quel usage correspond telle ou telle allocation.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
9 déc. 2010 à 02:38
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.

@++
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
7 déc. 2010 à 10:48
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.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
6 déc. 2010 à 23:02
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é.
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
6 déc. 2010 à 08:11
Ce que tu ne comprend pas c'est la manière dont le système gère la mémoire.Les blocs doivent rester contigus car on ne peut pas adresser une mémoire composée de petits morceaux.
La gestion de la mémoire est faite par le système et non par mon ingéniosité.Autrement dit,tu es en train de donner des leçons a microsoft,amusant non !?
Pour t'en convaincre,regarde la documentation de la fonction HeapReAlloc (MSDN),il est bien préciser que le pointeur de heap peut changer.
citation msdn
HeapReAlloc is guaranteed to preserve the content of the memory being reallocated, even if the new memory is allocated at a different location.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
5 déc. 2010 à 01:53
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 ;-)
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
5 déc. 2010 à 01:30
A noter également que c'est inutilisable en environnement multithread.

C'est évidement faisable et assez simplement ce que je dis. Les petits blocs entre les gros blocs sont utilisés pour l'allocation des petits objets justement.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
5 déc. 2010 à 01:07
pas vraiment compris ce que tu racontes. Tu ne confondrait pas memoire virtuelle et memoire physique ?
ToutEnMasm Messages postés 587 Date d'inscription jeudi 28 novembre 2002 Statut Membre Dernière intervention 13 décembre 2022 3
1 déc. 2010 à 09:40
Le changement d'adresse des tampons mémoires est un choix fait par le système pour optimiser la gestion de la quantité de mémoire disponible.En particulier éviter les trous inutilisables.
Même si c'était possible,je ne vois pas l'intérêt de le faire vu que ça diminue la quantité de mémoire disponible.
cs_patatalo Messages postés 1466 Date d'inscription vendredi 2 janvier 2004 Statut Modérateur Dernière intervention 14 février 2014 2
30 nov. 2010 à 20:49
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.

@++