C++

[C/C++] Malloc et occupation mémoire sous Win2000

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : [C/C++] Malloc et occupation mémoire sous Win2000

maestun

Voilà, j'ai trouvé ce bout de code sur le net :

Code :

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
/**
* fonction qui accepte une chaine en entrée
* qui ajoute à cette chaine la string ".cpp" et qui la
* renvoie
*/
char* extensionCPP(char *nomFichier)
{
//buffer qui va contenir la chaine en entier
char buffer;
//allouer un espace mémoire suffisant pour accepter la chaine
//+ l'extension .cpp
buffer = (char *)malloc(strlen(nomFichier)+4+1);
//copier le nom de fichier
strcpy(buffer, nomFichier);
//ajouter l'extension
strcat(buffer, ".cpp" );
//renvoyer la nouvelle chaine
return buffer;
}

OK, mais un truc me chagrine : comment va-t-on faire pour libérer l'espace mémoire pointé par buffer (alloué par malloc) ?
Pourra-t-on faire un free() de ce pointeur dans un autre fonction ? car là je me dis qu'après plusieurs appels à extensionCPP(), l'occupation mémoire va gonfler, non ?

Publicité

antp

Super Administrateur
Champion des excuses bidons

c'est la fonction appelante qui va devoir libérer la mémoire je suppose... et à part un free du pointeur renvoyer je vois pas vraiment d'autre solution

Message édité par antp le 09-04-2003 à 16:11:40

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire

philou_a7

\_o< coin ! >o_/

quand tu appelle ta fonction par :

Code :

szPipo=extensionCPP("blablabla" );

ton pointeur alloué est renvoyé dans la variable szPipo
donc un petit

Code :

if (szPipo) free(szPipo)

et hop

chrisbk

vi, un pointeur alloue (enfin la memoire sur laquelle il pointe) par malloc peut etre liberé par malloc dans n'importe quel autre endroit du prog (enfin, sauf dll mais passons).

Citation :

car là je me dis qu'après plusieurs appels à extensionCPP(), l'occupation mémoire va gonfler, non ?

mouais au vu de ce que fait ta fonction, deja un sacré d'appel, hein ?

nraynaud

lol

chrisbk a écrit :

mouais au vu de ce que fait ta fonction, deja un sacré d'appel, hein ?

Que je me souvienne bien, c'est bien 25 morts qu'il y a eu la dernière fois (connue) pour 10 octets de fuite ?¿?

edit : quote merdique

Message édité par nraynaud le 09-04-2003 à 16:58:33

chrisbk

nraynaud a écrit :

Que je me souvienne bien, c'est bien 25 morts qu'il y a eu la dernière fois (connue) pour 10 octets de fuite ?¿?

Heuh ?

(tain c la tempete de neige ici)

Harkonnen

Modérateur
Un modo pour les bannir tous

Non mais j'hallucine !! C'est quoi ce code de merde ? On ne doit JAMAIS retourner un pointeur alloué localement, y'a rien de plus crade et de plus dangereux !!!

---------------
J'ai un string dans l'array (Paris Hilton)

kadreg

profil: Utilisateur

http://www.programmationworld.com/ [...] numero=109

---------------
brisez les rêves des gens, il en restera toujours quelque chose... -- laissez moi troller sur discu !

ToxicAvenger

philou_a7 a écrit :

Code :

if (szPipo) free(szPipo)

[:toxicavenger] inutile de tester avant de désallouer. free(NULL) est dans la norme et ne produit rien. Pas de danger donc.

Message édité par ToxicAvenger le 09-04-2003 à 17:38:30

ToxicAvenger

maestun a écrit :

Voilà, j'ai trouvé ce bout de code sur le net :

Code :

buffer = (char *)malloc(strlen(nomFichier)+4+1);

[:toxicavenger] ca ne se caste pas un malloc.

Message édité par ToxicAvenger le 09-04-2003 à 17:38:23

Publicité

kadreg

profil: Utilisateur

ToxicAvenger a écrit :

[:toxicavenger] ca ne se caste pas un malloc.

Quand on essaye de le faire rentrer dans un char au lieu d'un char*, si.

[:pioupiou]

---------------
brisez les rêves des gens, il en restera toujours quelque chose... -- laissez moi troller sur discu !

ToxicAvenger

kadreg a écrit :

Quand on essaye de le faire rentrer dans un char au lieu d'un char*, si.

[:pioupiou]

et ne reviens pas

antp

Super Administrateur
Champion des excuses bidons

ToxicAvenger a écrit :

[:toxicavenger] inutile de tester avant de désallouer. free(NULL) est dans la norme et ne produit rien. Pas de danger donc.

idem pour le delete du c++ il me semble

---------------
mes programmes ·· les voitures dans les films ·· apprenez à écrire

Taz

bisounours-codeur

je rappelle un ruc sur les cast C. ça revient à dire au compilateur "FERME TA GUEULE"
alors si en plus y en a pas besoin, faut vraiment pas en mettre

mrbebert

chrisbk a écrit :

vi, un pointeur alloue (enfin la memoire sur laquelle il pointe) par malloc peut etre liberé par malloc dans n'importe quel autre endroit du prog (enfin, sauf dll mais passons).
...

C'est juste que c'est pas "propre" où y a une raison technique ?
Les DLL utilisent pourtant le même adressage virtuel, non :??:

philou_a7

\_o< coin ! >o_/

ToxicAvenger a écrit :

[:toxicavenger] inutile de tester avant de désallouer. free(NULL) est dans la norme et ne produit rien. Pas de danger donc.

c'est plus propre, et encore plus si tu as hooké les malloc/free pour tester les fuites memoires

de plus, sur certaines plateformes UN*X ou compatibles, le free sur pointeur null c'est pas top top

philou_a7

\_o< coin ! >o_/

mrBebert a écrit :

C'est juste que c'est pas "propre" où y a une raison technique ?
Les DLL utilisent pourtant le même adressage virtuel, non :??:

une fonction d'une DLL dans un thread alloue, et la fonction qui libere se retrouve appelée dans un autre thread : bobo :cry:

de toute façon, si une fonction doit retourner un buffer, il vaut toujours mieux que l'appellant l'alloue de lui-même pour en garder le controle total
Y a qu'a voir le carnage que ca peut etre dans certaines MFC avec des alloc faites on sait pas trop comment :sweat:

ToxicAvenger

philou_a7 a écrit :

c'est plus propre, et encore plus si tu as hooké les malloc/free pour tester les fuites memoires

de plus, sur certaines plateformes UN*X ou compatibles, le free sur pointeur null c'est pas top top

mauvais compilo, changer compilo. La norme dit qu'on peut le faire sans danger. Si ton compilo ne le permet pas, c'est qu'il ne respecte pas la norme établie par le C. Et donc à priori, tu peux faire n'importe quoi avec ton compilo, ton code généré aura un "comportement indéfini" (bah oui, s'il respecte pas la norme, il peut faire n'importe quoi du coup).

philou_a7

\_o< coin ! >o_/

Oui mais dans le monde réél, tu travailles souvent sur des machines que tu n'administres pas

Donc je prefere etre trop propre

ToxicAvenger

philou_a7 a écrit :

Oui mais dans le monde réél, tu travailles souvent sur des machines que tu n'administres pas

Donc je prefere etre trop propre

non mais la c'est la norme la plus conne qui soit... c'est comme de dire:

"ouais, je prefere réecrire moi meme malloc, c'est pas implémenté sur mon systeme"...

mauvais os, changer os.

philou_a7

\_o< coin ! >o_/

Citation :

je prefere réecrire moi meme malloc

:sarcastic:

p'tet pas exagerer non plus

je ne prefere appeler un free que si c'est vraiment necessaire, c'est tout

ToxicAvenger

philou_a7 a écrit :

Citation :

je prefere réecrire moi meme malloc

:sarcastic:

p'tet pas exagerer non plus

je ne prefere appeler un free que si c'est vraiment necessaire, c'est tout

ben 1 malloc = 1 free stout

maestun

Merci à tous pour vos réponses. J'ai aussi ce cas un peu chiant :
insertion d'une cellule à la fin d'une liste chaînée :

Code :

/* declarations */
struct typeCellule
{
char * nom;
char * prenom;
typeCellule * suivant;
}
typedef struct typeCellule * typeListe;
/* code */
/* insere une cellule a la fin d'une liste de cellules */
typeListe insertCell(char * nom, char * prenom, typeListe liste)
{
typeListe L;
typeListe temp;
/* allocation memoire pour une celule a inserer dans la liste chainée "liste" */
L = malloc(sizeof(struct typeCellule));
L->nom = malloc(strlen(nom) * sizeof(char) + 1);
L->prenom = malloc(strlen(prenom) * sizeof(char) + 1);
L->suivant = NULL;
/* recopie des données */
strcpy(L->nom, nom);
strcpy(L->prenom, prenom);
/* insertion de la cellule crée dans la liste */
if(liste != NULL)
{
temp = liste;
/* on va chercher la derniere cellule de la liste */
while(temp->suivant != NULL)
temp = temp->suivant;
/* chaînage de la derniere cellule avec la cellule créée */
temp->suivant = L;
return liste;
}
else
{
liste = L;
return liste;
}
}

question 1 : le "+ 1" dans les mallocs est-il nécessaire ?
question 2 : comment va-t-on pouvoir désallouer la mémoire allouée avec malloc() dans les fonctions appellantes ?

EDIT : précision supplémentaire : ce bout de code est appellé plein de fois car utilisé dans un service Win2000 (donc prog qui tourne en permanence), d'où la nécessité de libérer de la RAM !

Message édité par maestun le 10-04-2003 à 09:55:35

philou_a7

\_o< coin ! >o_/

1/ oui, le +1 est necessaire : strlen te donne la taille de la chaine sans le \0 final, donc tu rajoutes 1 pour prendre celui-ci en compte

2/ bah c'est simple : comme tout free de liste qui se respecte, tu va parcourir ta liste pour la liberer
Le plus simple est de faire une fonction recursive pour ca :

en pseudo code ca donne a peu pres ca :

Libere(liste)
{
si (liste)
{
si (liste->suivant) alors Libere(liste->suivant)
free(liste->champ_de_donnée) // pour chaque champ...
free(liste)
liste=null
}
}

maestun

philou_a7 a écrit :

Merci bcp !
si je comprends bien, il est possible de faire "free(ptr)" si le "ptr = malloc(x)" a été fait dans une autre fonction ?

philou_a7

\_o< coin ! >o_/

oui, tant que tu ne te balade pas entre plusieurs threads, ou dlls, etc

jagstang

Pa Capona ಠ_ಠ

Harkonnen a écrit :

Non mais j'hallucine !! C'est quoi ce code de merde ? On ne doit JAMAIS retourner un pointeur alloué localement, y'a rien de plus crade et de plus dangereux !!!

Je vois pas en quoi c'est dangeureux. il suffit de tester à la sortie. Jette un oeil sur les listes et les files. que font les fonctions d'après toi ?

Tetragrammaton IHVH

dieu unique => pensée unique

JagStang a écrit :

Je vois pas en quoi c'est dangeureux. il suffit de tester à la sortie. Jette un oeil sur les listes et les files. que font les fonctions d'après toi ?

Rien à voir, ces fonctions font une allocation sur le heap et non localement. Une variable locale (à une fonction) est désallouée à la fin de la fonction donc il n'est pas possible de la retourner (enfin si, c'est possible mais c'est mal )

---------------
"Dieu a exploité tous nos complexes d'infériorité, en commençant par notre incapacité de croire à notre propre divinité." - Emil Michel Cioran

Harkonnen

Modérateur
Un modo pour les bannir tous

JagStang a écrit :

Je vois pas en quoi c'est dangeureux. il suffit de tester à la sortie. Jette un oeil sur les listes et les files. que font les fonctions d'après toi ?

Je plussoie Tetragrammaton !
Par définition, une variable allouée localement est détruite à la fin de la fonction. Donc si tu retournes un pointeur non alloué, la zone mémoire à laquelle il fait référence n'existera plus en sortant de la fonction et tu te retrouves avec un pointeur fou, à moins que tu n'alloues la mémoire dans la fonction. Mais ça veut dire que tu dois la libérer en dehors de la fonction, ce qui est dangereux dans le cas d'un projet sur lequel plusieurs personnes travaillent : tu peux être sur que 9 fois sur 10, la RAM ne sera pas libérée.

Si on tient absolument à retourner un pointeur, le mieux est de l'allouer avant d'appeler la fonction.

---------------
J'ai un string dans l'array (Paris Hilton)

Dieze Inecloude

Mercenaire en SSII

Tetragrammaton IHVH a écrit :

Oui effectivement, que le pointeur soit local ou global ne change rien, la mémoire est toujours allouée sur le tas, thanx God..;-)
Si c'est possible, de facon saine, car ta variable locale est forcément recopiée pour retourner la valeur à l'appelant dans le cadre de la convention de passage de paramètres en vigueur sur le compilo.

---------------
"We are not enemies, but friends. We must not be enemies. Though passion may have strained, it must not break our bonds of affection. The mystic chords of memory will swell when again touched, as they surely will be, by the better angels of our nature."

VisualC++

J'va y penser ...

On peut faire un truc genre ca pour alloue en dehors de la fonction.

Code :

char* pBloc = NULL;
pBloc = (char*) malloc(lafonction(pBloc, .... les params));
if (pBloc != NULL)
lafonction(pBloc, .... les params);
else
erreur d'alloc
int lafonction(char* pBloc = NULL, ... les params) {
if (pBloc == NULL)
return LaTailleDontOnABesoin;
... reste de la fonction
return 1;
}

Publicité

FORUM HardWare.fr

Programmation

C++

[C/C++] Malloc et occupation mémoire sous Win2000

Sujets relatifs
--LIBERATION MEMOIRE-- Garbage collector	malloc()
c coi une fuite de mémoire ?	[C embarqué] différence entre un accès I/O et accès mémoire.
Cast malloc : A faire ou pas ?	[C/C++]Petit problème de malloc
obtenir la taille de la mémoire libre...	petit probleme de memoire!!!
[C] logiciel pour verifier que tout l'espace alloué par des malloc etc	Ou récupérer l'info sur l'occupation mémoire dans windows??
Plus de sujets relatifs à : [C/C++] Malloc et occupation mémoire sous Win2000

Page générée en 0.111 secondes