Version imprimable
Bonjour a tous,
Voila je voudrais savoir comment je peux m'y prendre pour savoir si le realloc() que j'utilise a fonctionné.
J'ai fais un malloc pour 10 char (admettons), qui, si besoin est, est reduis à 5 char(hop le realloc).
Donc voila, j'ai fais un printf("%d", sizeof(le_pointeur_du_tab)); a deux moments distincts, mais je ne suis pas sur que cela soit ca.
merci de votre aide.
Cordialement.
Bonjour,
sizeof(le_pointeur_du_tab) te retourne la taille d'un pointeur et pas de la zone mémoire pointée.
Pour savoir si le realloc a fonctionné, et bien, il suffit tout simplement d'en tester le retour :
Tu noteras qu'on passe par une variable intermédiaire (pc_new) pour le realloc. Cela évite de perdre la première adresse allouée en cas d'échec du realloc.Code:
2
3
4
5
6
7
8
9
10
11
12
13
en faite mon realloc fonctionne, car après j'ai accés au données du tableau. La vérif' que je voulais était la vérif' de la taille : si la taille de l'espace mémoire réservée était bien plus petit que l'ancien.
merci pour ta réponse rapide.
Le realloc et le malloc te fournissent une zone mémoire d'au moins le nombre d'octets que tu as demandé. Mais rien n'empêche l'implémentation de t'en fournir plus. Cela n'est pas ton problème en tant que programmeur. Tout ce que tu sais, c'est qu'à partir du moment où l'adresse retournée est non nulle alors tu peux écrire sur le nombre d'octets que tu as demandé.Citation:
Envoyé par mixka13
ok, je comprend, le truc c'est que en temps que jeune programmeur (étudiant en info et passionné par la mm occaz) je tente d'éviter les fuites de mémoire (memory leak ;) )
merci a toi
La fuite mémoire c'est un malloc ou un realloc pour lequel tu ne fais pas de free correspondant.Citation:
Envoyé par mixka13
Faire un realloc sur une taille inférieur est rarement pertinent pour au moins 3 raisons. 1/ Les cas où tu vas souhaiter récupérer les quelques octets en trop sont en réalité très rares. 2/ Tu prend le risque d'avoir un realloc qui échoue alors que tu avais déjà une zone d'au moins la taille que tu voulais. 3/ Rien ne te garantie que le nouveau bloc qui t'es retourné a exactement la taille que tu demandes.
Je prend un exemple. Dans les systèmes embarqués, la mémoire est souvent gérée à partir de pool de blocs mémoires de taille fixe, pour différentes raisons d'optimisations. Par exemple, tu as une liste de blocs mémoires de 64 octets, une liste de 512 octets et une liste de 10ko. Lorsque tu fais un malloc(1) ou un malloc(64) tu obtiens un bloc de 64. Lorsque tu fais un malloc(65) à malloc(512) tu obtiens toujours un bloc de 512 octets, et ainsi de suite.
Donc si tu fais d'abord un malloc(24), puis sur cette zone une realloc(10), tu obtiendras les deux fois un bloc de 64 octets !
De la même façon, si tu fais un malloc(300) puis un realloc(10), tu prend le risque d'avoir ton realloc qui échoue si tous les blocs de 64 octets sont occupés. Certes cela te permettrait de libérer un bloc de 512, mais dans la plus part des cas, tu auras une meilleure optimisation en travaillant sur tes algos et tes flux de données.
Enfin, en guise de conclusion, la meilleur façon d'éviter les fuites mémoires consiste encore à ne pas faire d'allocation dynamique :mrgreen:
:king:Citation:
Envoyé par mixka13
c'est sur mais bon le sur dimensionnement de tableau dû au statique c'est pas merveilleux ... :mouarf:
sizeof ne permet pas de connaitre la taille de la zone pointée. C'est toi qui a appelé malloc() et realloc() avec une certaine taille, c'est à toi de conserver cette taille. Il n'y a aucun moyen, en C standard, de savoir si realloc() avec une taille plus petite a effectivement libéré de la mémoire. (c'est peu probable avec le petites tailles et les petites variations).Citation:
Envoyé par mixka13
Attention, il y a quelques précautions d'usage avec realloc() :
http://emmanuel-delahaye.developpez....es.htm#realloc
Tu aurais probablement de meilleurs résultats en créant un nouvel objet plus petit (malloc()) et en faisant la copie à la main (puis en libérant l'ancien objet, évidemment). Pour une chaine, la fonction POSIX.1 (très portable) strdup() fait ça très bien.
Se méfier des raisonnements trop simplistes ou trop scolaires ...Citation:
Envoyé par mixka13
Tout dépend de l'usage. Souvent, un peu de gâchis mémoire permet de développer rapidement du code fiable et simple. As-t-on vraiment besoin de plus ? Chaque cas doit être analysé. Ce qui compte le plus, en général, c'est la robustesse. Le cout de développement est aussi un facteur important dans le monde réel...
oui, je suis d'accord, je n'utilise d'ailleurs pas des allocation dynamique à tour de bras, il faut cerner le problème pour trouver la méthode la plus adéquat (et la moins casse pieds à mettre en place :yaisse2: )