Discussion :

[souviron34]

voilà du concret comme j'aime bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAA|BBBBBBBB|CCCCCCCCCCC

du coup moi ça m'intéresse fortement le coup de libérer de la mémoire pour avoir

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAA|CCCCCCCCCCC

et non

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAA|_________|CCCCCCCCCCC

peut tu développer un peut le truc des listes chaînées, j'ai pas trop compris ! Désolé

comme, souvent (pas tout le temps), tu as des tableaux qui perdurent pas rapport à d'autres (dans ce cas C par rapport à B), tu ne peux pas "récupérer" simplement les trous.

Donc, pour bénéficier au mieux des trous laissés au fur et à mesure de l'éxécution du programme, le mieux est d'avoir des "petites" allocations plutôt qu'une grosse.

Si tu as par exemple le tableau B que tu devras ré-allouer plusieurs fois car il change de taille au fur et à mesure de l'éxécution, tu auras par exemple :

1. 1er appel : 50 emplacements
   
2. 2ième appel : 100 emplacements.

Comme tu as alloué C entre-temps, il n'y a pas la place d'agrandir B là où il est situé. La routine de ré-allocation ira donc trouver le premier emplacement disponible (à la fin de C), allouera 100 emplacements, copiera les éléments des 50 anciens emplacements à l'endroit des 50 nouveaux, et laissera un trou de 50 éléments.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|BBBBBBBBBBBBBB|CCCCCCCC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|______________|CCCCCCCC|BBBBBBBBBBBBBBBBBBBBBBB

Tu fais ça plusieurs fois, et tu auras de gros trous dans ta mémoire totale, qui ne seront pas facilement récupérables.

Si maintenant tu fais une liste chaînée, chaque nouvel élément se fait par allocation. Le fait d'en détruire un crée un "petit" trou. Mais surtout, ce trou est EXACTEMENT de la taille d'un élément. Donc, à l'allocation suivante, on pourra très bien se retrouver AU MEME emplacement physique.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|BBB|CCCCCCCC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|B_B|CCCCCCCC

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|BBB|CCCCCCCC

Et même si entre-temps tu as alloué autre chose, à chaque fois ce sont de petits trous, et plus c'est découpé en tranches "élémentaires" (comme un élément d'une liste chaînée), plus il sera facile de remplir les trous, et donc de minimiser l'augmentation de la mémoire (et même de la stabiliser une fois que tu auras atteint le maximum de données possible).


Maintenant, pour vraiment faire qu'un programme récupère vraiment la mémoire allouée dynamiquement, il faut une biblothèque spéciale de malloc, et surtout gérer de manière beaucoup plus complexe les pointeurs (ou bien libérer dans l'odre inverse d'allocation, ce qui très souvent n'est pas possible). Ces bibliothèques existent, mais ne marchent réllement bien que si la structure d'allocation est simple (voir mon exemple dans le post au dessus : comment faire pour avertir le programme que p2 a été modifé ???). Ou alors il faut s'assurer que ce qu'on veut libérer et ré-allouer soit le dernier élément (le C dans l'exemple).

Mais passer de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|______________|CCCCCCCC

à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

AAAAAAAAAAAA|CCCCCCCC

est pratiquement impossible la plupart du temps.
(le seul vrai moyen est de le faire soi-même, et c'est franchement pas utile dans l'écrasante majorité des cas, et en plus c'est compliqué)

[dapounet]

Ici on cherche a eviter une copie de la structure, mais le but premier n'est pas d'economiser de la memoire. Le but est d'eviter le cout de la copie.

Bah ça a aussi l'avantage de prendre moins de place. En fonction de la taille de la structure ça peut avoir de l'importance ou pas.

donc en fait en gros la plupart des utilisations des pointeurs de structure comme tu le présentes sont pour économiser la PILE des arguments à une fnction, pas la mémoire.

La pile c'est rien d'autre que de la mémoire hein.

Sauf que, à cause du passage de paramètres par valeur en C, même pour les éléments eux-même il faut passer leur adresse pour qu'ils puissent être modifiés.

Je ne vois toujours pas le rapport. J'ai dit le contraire quelque part ?