Discussion :

[Haze.]

Bonjour,

J'ai vu en cours les fonctions malloc() et free(), ainsi que le concept de tableau à taille dynamique.

1) Ce code permet d'augmenter la taille du tableau de 10 postes supplémentaires à chaque appel de la fonction agrandir (aucune valeur n'est manipulée dans le tableau mais le principe est là).
Ma façon de procéder est-elle correcte ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
#include <stdlib.h>
#include <stdio.h>
 
 
int* agrandir(int tab[], int *taille)
{
	int *t_temp = NULL;
	int i = 0;
 
	t_temp = (int*) malloc(sizeof (int) * (*taille + 10));
	/* on recopie les valeurs dans le nouveau tableau */
	for (i=0; i < *taille; i++)
	{
		t_temp[i] = tab[i];
	}
 
	*taille += 10;
	free(tab);
 
	/* on retourne la nouvelle adresse de tab */
	return t_temp;
}
 
 
int main()
{
	int *tab = NULL;
	int taille=0;
 
	tab = (int*) malloc(sizeof (int) * 50);
	taille = 50;
 
	printf("nombre de postes : %d\n", taille);
 
	tab = agrandir(tab, &taille);
	printf("nombre de postes : %d\n", taille);
	free(tab);
 
	return 0;
}

2) Je me suis un peu documenté (man malloc et FAQ C) et j'ai vu la fonction realloc, qui m'a l'air de faire la même chose.
Est-ce le cas ?

3) J'ai aussi une question sur le fonctionnement de la fonction free :
Quand on déclare un tableau à dimension fixe

Code :

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

int tableau[50];

tableau est de type int[50] donc le langage sait que 50 postes int sont réservés en mémoire à partir de l'adresse de tableau.
Mais si on veut une taille dynamique, tableau est déclaré avec :

Code :

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

int *tableau;

donc le type est int*, alors comment fait la fonction free pour libérer la mémoire si la taille n'est stockée nulle part ?
Mes professeurs m'ont dit que c'est parce que la mémoire vive possède une zone "différente" qui est réservée aux allocations dynamiques... mais je ne vois pas le rapport.
Comment free connaît le nombre de postes à libérer à partir de l'adresse qui lui est passée en argument ?


Merci

[Emmanuel Delahaye]

J'ai vu en cours les fonctions malloc() et free(), ainsi que le concept de tableau à taille dynamique.

1) Ce code permet d'augmenter la taille du tableau de 10 postes supplémentaires à chaque appel de la fonction agrandir (aucune valeur n'est manipulée dans le tableau mais le principe est là).
Ma façon de procéder est-elle correcte ?

Il est techniquement possible de faire comme tu as fais, mais il est préférable d'utiliser realloc(). D'autre part, il faut toujours tester ce que retourne les fonctions d'allocation. Un échec est toujours possible (NULL).

http://emmanuel-delahaye.developpez....tes.htm#malloc
http://emmanuel-delahaye.developpez....es.htm#realloc

3) J'ai aussi une question sur le fonctionnement de la fonction free :
Quand on déclare un tableau à dimension fixe

Code :

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

int tableau[50];

tableau est de type int[50] donc le langage sait que 50 postes int sont réservés en mémoire à partir de l'adresse de tableau.

Exact. En fait, la taille est une expression constante qui est utilisée pour générer du code où tout adressage est pré-calculé par le compilateur (quand c'est possible). On gagne en vitesse et en taille de code, mais on perd en souplesse.

Mais si on veut une taille dynamique, tableau est déclaré avec :

Code :

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

int *tableau;

donc le type est int*, alors comment fait la fonction free pour libérer la mémoire si la taille n'est stockée nulle part ?
Mes professeurs m'ont dit que c'est parce que la mémoire vive possède une zone "différente" qui est réservée aux allocations dynamiques... mais je ne vois pas le rapport.
Comment free connaît le nombre de postes à libérer à partir de l'adresse qui lui est passée en argument ?

Faut pas trop en demander à un prof standard...

Lors de la demande d'allocation mémoire (*alloc()), on passe une taille qui, si l'allocation réussit, est probablement enregistrée 'quelque part', associée à l'adresse du bloc alloué. Lors du free(), l'adresse est recherchée et le bloc est libére. Mais je ne suis même pas sûr que la taille du bloc conservée... C'est un provblème d'implémentation qui ne concerne pas le programmeur.

Si on veut connaitre la taille du bloc alloué, soit on initialise le bloc avec une valeur et on met une 'sentinelle' au bout qui soit différente de cette valeur (genre chaine de caractères...), mais ça 'bloque' une valeur, soit on prend les précautions nécessaires pour conserver la taille. Le plus évident est de créer une structure :

Code :

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

1
2
3
4
5
6
 
struct tabdyn
{
   T *tab;
   size_t nb_elem;
};

[salseropom]

Salut,
les cast lors du malloc ne servant à rien
teste si le malloc ne t'as pas renvoyé NULL
pour un malloc, il vaut mieux faire

Code :

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

1
2
3
4
5
6
 
int * pint=malloc(N*sizeof(*pint))
if(pint==NULL)
{
/* erreur */
}

c'est mieux que de faire

Code :

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

1
2
3
4
5
6
 
int * pint=malloc(N*sizeof(int))
if(pint==NULL)
{
/* erreur */
}

car si tu changes le type de pint, tu ne changeras rien dans le malloc...

[DaZumba]

Comment free connaît le nombre de postes à libérer à partir de l'adresse qui lui est passée en argument ?

Voir cette discussion.

[Haze.]

Il est techniquement possible de faire comme tu as fais, mais il est préférable d'utiliser realloc()

Comme je n'ai pas vu cette fonction en cours, je voulais m'assurer d'avoir compris le principe de la taille dynamique

D'autre part, il faut toujours tester ce que retourne les fonctions d'allocation. Un échec est toujours possible (NULL).

teste si le malloc ne t'as pas renvoyé NULL

Oui en effet... je ferais attention dorénavant. J'enlèverai aussi les casts devant l'appel de malloc.

Merci à tous pour vos réponses très instructives.

Faut pas trop en demander à un prof standard...

Ho... je dirai plutôt, prof anti-standards.