Voilà,
 
Encore un problème avec le C. J'ai un programme qui utilise la fonction malloc. Il tourne très bien sur mon portable, mais pas sur les pc de mon école. Problème : il faut que je le rende demain.
La fonction qui utilise le malloc est récursive, donc bouffe pas mal de mémoire. J'ai essayé de modifier la taille des arguments de malloc, mais rien n'y fait.
Y aurait-il une solution ?

tu devrait expliquer un peu plus je crois

Tu fais plein de malloc, mais est que t'en libères aussi par hasard (juste au cas où, sans être méchant)? Pourquoi ne pas faire un gros malloc de tout ce dont tu as besoin puis gérer tout ça dans une grosse structure (ce qui éviterait de perdre quelques dizaines d'octets à chaque allocation)?
 
Sinon c'est vrai que plus d'information serait la bienvenue.
 

soit tu passes par le malloc / memcpy / free soit par le malloc / realloc / free
 
en gros :
 
 
 
while..
 
delete (ptr2);
char *ptr =(char*) malloc (size);
char *ptr2 = (char*) malloc (new_size);
mempcy(ptr2,ptr);
delete (ptr);
 
ou
char *ptr =(char*) malloc (size);
....
ptr = (char*) realloc (new_size);
 
delete(ptr);
ps : si free plante -> probleme de size

 
hé !? un delete c sur un objet, pas sur un espace mémoire réservé par un malloc. normalement on fait un free...
ça passe ça !?

A priori non...
Bien sur sur certaines implementations il n'y a pas de Pb.

Sous Borland C 3, quand j'ai transformé mes malloc() en new, les free() oubliés n'ont pas posé de pb.
 
Habituellement (me semble-t-il), pour l'allocation mémoire, on fait (d'après les livres)
malloc() et free()
 
ou new xx et delete.
 
Les compilos font le boulot de nous comprendre  .

Si ca marche po sur les becannes de ton ecole, c parceke il faut que tu compiles ton source sur la becanne de l'ecole.
C peut etre ca, si tu l'a pas fait c meme sur.
Sinon, joue avec les options de compilations...

avec un peu de bol, il est intelligent et le sait...

les becanes tournent sous le meme OS chez toi et a l'ecole?

 
mmm c pas forcement une question d'OS....

n

 
oui mais ca peut

sous linux/unix , pas de pb , la ram est liberer correctement ( meme si on oublie de faire les free )  
sous win , ca plante hyper vite si tu ne libere pas la ram .
moi , je conseille de bien verifier qu'il y a des free avec chaque malloc .<--- syntaxe du C ansi

CARBON_14 a écrit a écrit : Sous Borland C 3, quand j'ai transformé mes malloc() en new, les free() oubliés n'ont pas posé de pb. Les compilos font le boulot de nous comprendre  .

 
c'est total bullshit.
c'est bien de donner des faux bons conseils
mais faut assumer apres.
 
Bon alors pour ceux qui n'auraient pas compris:
malloc et free c'est pour allouer des blocs memoires sans type et c'est a reserver pour la programmation C (tu peux utiliser
malloc en C++ mais tu cours le risque de t'emmeler les pinceaux).
New et Delete (ou sa variante delete[] pour les tableaux d'objets) c'est pour allouer des objets et ca ne fait pas que reserver la memoire ca appelle le constructeur et le destructeur de l'objet. Donc on ne melange pas les deux.
 
A+
LEGREG

Il n'y a ni constructeur, ni destructeur de primitifs. Et quand on alloue un tableau avec new chacune de ses valeurs n'est-elle pas indéfinie?

 
Je voulais principalement signaler qu'on pouvait NE PAS AVOIR D'AVERTISSEMENT DU COMPILO quand on utilise des opérateurs "mélangés" par étourderie (<- à éviter pour les futurs pros). C'était uniquement appliqué à des chaînes.
 
Donc, quand on passe du C au C++, vaut mieux tout réécrire.