Discussion :

[space_56]

Bonjour,

Pourquoi doit-on toujours allouer de la mémoire avec malloc pour un tableau ?
On peut très bien créer des tableaux sans avoir recours à malloc.

Et pourquoi veut-on libérer la mémoire, avec free ?
Sans utiliser free, cela ne provoque pas d'erreur.

Merci de votre aide.

[TheGzD]

C'est une question de choix :
- soit du gères les allocations de mémoire statiquement
- soit tu les gères dynamiquement (avec malloc puis free)

Ça fait partie des bases du C => je te conseille vivement d'aller consulter un des tutos pour débutant.

[saloua]

Bonjour,
Comme on te l'a dit c'est une question de choix. Toutefois, quoique c'est facile de créer des tableaux sans malloc , l'inconvénient c'est que c'est tableaux prennent beaucoup d'espace mémoire et ce parfois inutilement d'où le gaspillage de la mémoire. Supposons que tu dois créer un tableaux mais tu connais pas vraiment le nombre exacte de cellules dont tu as besoin, dans ce cas tu dois estimer le nombre nécessaire et pour ne pas avoir des problème au cours de l’exécution du programme (dépassement de la taille du tableau), tu choisirai un nombre très grand soit N. tu vas donc déclarer ton tableau en utilisant ce N comme étant la taille ce qui va réserver N*x octets de la mémoire si chaque cellule du tableau a besoin de x octets pour être représentée dans la mémoire. Mais en passant à l’exécution, tu peux te rendre compte que tu as uniquement besoin de la moitié de la taille N. donc tu utiliseras effectivement 0.5*N*x octets et les 0.5*N*x octets te sont encore réservés mais sans aucune utilité.
Tu peux te dire bon je diminue le N, mais tu peux en cours de l’exécution te rendre compte que tu as encore besoin d'autres cellules et là tu te coince car il te sera impossible d'avoir plus de cellule dans le tableau puisque sa taille est définie (et elle le doit être) dans la déclaration.
D'où la solution efficace et qui offre beaucoup de souplesse c'est l'allocation dynamique de la mémoire (par malloc) : j'alloue quand j'ai besoin et je libère (free) la mémoire quand j'en ai plus besoin! et donc l'avantage est: pas de gaspillage de mémoire d'une part et aucune contrainte sur la taille du tableau.
voilà, j'espère avoir été claire.

[Thierry Chappuis]

Ce n'est pas uniquement une question de choix. Parfois, il arrive que la taille d'un tableau soit connue au moment de la compilation, parfois ce n'est pas le cas. Si la taille d'un tableau ou d'une structure de donnée n'est pas connue à la compilation, l'allocation dynamique s'impose. Si la taille de la structure de donnée, tu as le choix entre allocation statique ou dynamique. Si la taille de la structure de donnée n'est pas appelée à être modifier lors du fonctionnement du programme, utiliser l'allocation statique convient parfaitement.

Naturellement, selon la durée de vie de la structure de donnée, il peut s'avérer impossible d'allouer l'espace mémoire pour des tableaux de grande taille sur la pile, pour des questions de taille de pile. Ainsi, pour les grandes structures de données, il faut parfois allouer sur le tas, même lorsque la taille est connue à la compilation.

Avec mes meilleures salutations

Thierry

[Obsidian]

Bonjour,

À mon tour d'en rajouter une louche.

Pourquoi doit-on toujours allouer de la mémoire avec malloc pour un tableau ? On peut très bien créer des tableaux sans avoir recours à malloc.

Personne n'a dit qu'il fallait toujours le faire. Tu peux effectivement déclarer des tableaux comme des variables locales et heureusement.

Et pourquoi veut-on libérer la mémoire, avec free ?
Sans utiliser free, cela ne provoque pas d'erreur.

Non, mais ça ne libère pas la mémoire non plus, et ça c'est très ennuyeux. Si ton programme prend fin, c'est le système qui va faire le ménage pour toi, ce qui déja n'est pas très propre. Mais s'il ne se termine pas et qu'il boucle pour revenir au début, par exemple, alors c'est une fuite de mémoire : tu vas successivement allouer des blocs sans jamais les libérer, jusqu'à épuisement de toute la mémoire disponible.

Il faut aussi tenir compte du fait que lorsque l'on programme, il faut veiller à écrire des programmes qui restent dans les capacités de la machine. Allouer 10 octets de mémoire, ce n'est pas du tout la même chose qu'allouer 10 Go. Et ça, c'est une notion qui se perd à mesure que la puissance des machines augmente, que les niveaux d'abstraction des langages se superposent, éloignant le programmeur de sa machine, et que celles-ci sont secondées par des systèmes de swap toujours plus performants. Ça doit faire très longtemps maintenant que quelqu'un ici ait vu un « Out Of Memory » de ses yeux…

Pour entrer un peu plus dans les détails maintenant :

• Les tableaux déclarés comme des variables locales prennent place dans la pile. Celle-ci est relativement limitée en taille, mais est très importante pour le fonctionnement de toute l'application. Il est donc nécessaire de ne pas en abuser, et de la libérer le plus vite possible.
• Une variable locale est censée toujours être valide dès lors qu'elle est déclarée. Un appel à malloc(), lui, peut échouer et te repondre « désolé, plus de place » ;
• Tu peux utiliser des variables statiques ou globales mais là, pour le coup, il n'y a plus moyen de les libérer si elles ne servent plus ;
• Une variable locale disparaît à l'issue de son bloc et ce n'est pas forcément souhaitable : il se peut que la mémoire allouée servent à contenir des données qui doivent être renvoyées à une fonction de plus haut niveau ;
• Comme dit plus haut, tu peux ne pas savoir à l'avance de quelle quantité de mémoire tu vas avoir besoin, ni sur combien de temps : c'est typiquement le cas des listes chaînées, par exemple, où tu dois déclarer de nouveaux maillons au cours du temps, puis les insérer au milieu d'une liste existante.

Il y a un phénomène en informatique qui est apparu il y a une vingtaine d'années et qui provoque l'incompréhension de beaucoup d'étudiants sur ce sujet : Java. Peut-être est-ce de ce monde que tu viens. Certes, ce style de programmation et notamment l'usage d'un garbage collector existaient déjà, mais cela a pris des proportions considérables depuis le développement de ce langage qui séduit beaucoup de débutants parce qu'il a l'air plus facile à aborder.

En Java, quand on veut créer un nouvel objet, on fait systématiquement « TypeDObjet x = new TypeDObjet » et il n'y a pas de libération… en apparence ! On renvoie l'objet si on a besoin de le faire, sinon on quitte la fonction tranquillement sans s'en soucier. Le problème, c'est que le travail en question n'a pas disparu mais est complètement masqué aux yeux du programmeur, qui n'y a plus accès. Et la complexité que cela peut représenter lui échappe.

Il faut bien se rendre compte que pour que ce système fonctionne, il faut un compteur de références, comme pour un système de fichiers, qui permet au GC de savoir si l'objet en question est toujours utilisé par une partie du programme ou pas, puis appeler automatiquement une procédure à intervalles réguliers pour faire le ménage. Il faut donc une certaine quantité pour faire la gestion de tous ces objets, une bibliothèque de runtime conséquente et bien conçue, et une bonne quantité de temps CPU sur l'exécution totale du programme pour faire cela, ainsi qu'une structure sous-jacente liée à tous les objets crées (attribuée à la classe-mère Object) pour que ça marche.