Discussion :

[hunter001]

Bonjour,
Désolé pour le titre, mais une application de mon entreprise plante au bout d'un certain temps.
j'ai besoin d'une aide sur un point voici le code :

Code :

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

1
2
3
4
5
6
7
 Buffer = malloc(300);
  if ( (Buffer = malloc(300)) == NULL ) 
 blabla
else
 
free(buffer);
endif

J'ai l'impression qu'il y a une double allocation mémoire sur le buffer,
Est-ce pénalisant ?
Est-ce que ca ne change rien étant donné que c'est la même variable ?

J'ai bien un free dans mon else, mais le 2ème malloc n'est pas libéré ???



Merci pour votre aide.

[Laurent Gomila]

Salut

Tout d'abord merci à l'avenir d'utiliser un titre explicite en rapport avec ton problème. De plus, ici rien n'est urgent et les membres répondent ce qu'ils peuvent quand ils peuvent. Je t'invite à lire les règles du forum si ce n'est déjà fait.

Ensuite, tu perds effectivement le buffer précédent avec la seconde allocation. Si celle-ci réussit tu auras une fuite mémoire, si elle échoue tu vas entrer dans le else et faire un "free(NULL)" ; je ne sais pas si c'est autorisé ou si ça mène à un plantage (en C++ on n'utilise plus malloc). Je te propose de simplement virer la seconde allocation dans le if, ainsi que le else qui ne sert à rien.

[hunter001]

Ok merci pour ta réponse, ca confirme ce que je soupçonnait pour la fuite mémoire.

Désolé pour le titre.

[hunter001]

Pour compléter ma réponse, Le else nous sert à tracer les erreurs, docn si y a pas d'allocation, on mets un message informatif.


Sinon tu dit qu'on n'utilise plus de malloc en C++, qu'utilise ton à la place ?

[khayyam90]

malloc est remplacé en c++ par l'utilisation de new

Pour compléter ma réponse, Le else nous sert à tracer les erreurs, docn si y a pas d'allocation, on mets un message informatif.

bonne idée, mais il ne faut tester que le pointeur, pas toute la réallocation comme l'a dit loulou24

[Aurelien.Regat-Barrel]

On utilise new:
http://c.developpez.com/faq/cpp/?pag...S_pourquoi_new
si l'allocation échoue, une exception est levée. Pas besoin de tester le succès alors, et tu peut gérer les erreurs d'allocation à un niveau plus élevé, de manière globale.

[hunter001]

Ok nickel ça !!
Mais après investigation, j'apprend que l'on n'utilise pas le new pour une histoire de compilateur trop ancien et gratuit qui ne gère pas les exceptions.

Et que pour changer de compilateur, ya plein de conséquence (gestion des erreurs, revérification des codes .....)

bref, apparemment on va continuer avec le malloc.

En tout cas merci pour votre aide.

[JolyLoic]

J'espère que vous êtes conscients que ne pas utiliser new interdit tout usage des classes ou de la bibliothèque standard du C++. Dans ce cadre, êtes vous certains de ne pas vouloir coder en C plutôt ?

[hunter001]

En fait grace au problème qu'on vient d'avoir, on va faire le forcing auprès des responsables pour changer de compilateur !
Ca nous permettra d'être plus évolutif dans notre programmation et d'éviter ce genre d'erreur idiote!

Maintenant, j'espère qu'il ne feront pas les sourdes oreilles.

[Aurelien.Regat-Barrel]

Mais après investigation, j'apprend que l'on n'utilise pas le new pour une histoire de compilateur trop ancien et gratuit qui ne gère pas les exceptions.

Quel compilateur ?
Le cas courant est celui de VC++ 6 où new renvoie NULL comme malloc, au lieu de lever une exception.
VC++ 6 n'est pas gratuit, est très vieux (1998 : il est sorti avant la norme C++...), possède de nombreux autres problèmes. Son support étendu s'arrête d'ailleurs le mois prochain, autant dire que du point de Microsoft ce produit n'existera plus.
La version 7 et 7.1 sont sortis, la 8 arrive très prochainement (si vous devez changer VC++, attendez celle là). La version 7.1 est gratuite.
Il existe aussi g++ comme très bon compilateur gratuit.
Ca te fait des arguments en plus pour changer

[hunter001]

Tu va rire, nous utilisons Visual C++ 5 fourni avec le logiciel microsoft studio developer 97 !

Bon j'envoi un petit mail à mes responsables avec tes arguments. Merci

[Matthieu Brucher]

En plus, passer à VS 7.1 ou 8 ne sera pas trop trop difficile, c'est dans la continuité

[Higestromm]

Personellement j'ai jamais vu un new ou un malloc qui plantais... Et franchement si tu teste a chaque fois que tu alloue de la mémoire tu vas perdre un peu en performance pour rien celon moi...

[Matthieu Brucher]

Il suffit que tu aies une grosse appli et qu'il n'y ait plus assez de mémoire pour que ça puisse planter, il y a même un joli avertissement qui s'affiche dans ces conditions.
Et si tu fais une allocation trop grosse sans t'en rendre compte ?

[Aurelien.Regat-Barrel]

Ou si le construteur de l'objet alloué lève un exception.
Passer de VC++5 à VC++8 va tout de même nécessiter un peu de travail je pense. VC++5, c'est la préhistoire

[Higestromm]

Il suffit que tu aies une grosse appli et qu'il n'y ait plus assez de mémoire pour que ça puisse planter, il y a même un joli avertissement qui s'affiche dans ces conditions.

Ca veux dire plus de swap et plus de mémoire du tout ??? Je me demande si c'est ton appli ou ton OS qui plante en premier dans ces conditions

Code :

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

Ou si le construteur de l'objet alloué lève un exception.

C'est vrai, j'avais pas penser à ce cas précis.

[Matthieu Brucher]

Du travail dans le bon sens