Delete sur un tableaux d'objets

Bonjour,

J'aimerai savoir comment faire un delete propre pour supprimer tous les objets de tabResult?
En fait je crée un tableau d'objets, dans lequel j'insère des objets.

Code:

---

1 2 3 4 5 6

TCompareResult * tabResult; TCompareResult tabResult = new TCompareResult[nbCombinaison];   result = new TCompareResult(); tabResult[indexCombinaison] = * result;

---

Ps: Comment faire une allocation propre, c'est à dire savoir si le new a bien fonctionné?

Merci

Tout est expliqué dans la FAQ ici : http://c.developpez.com/faq/cpp/?pag...EURS_new_array

Accessoirement ton code est faux je ne vois pas vraiment où tu veux en venir...

D'accord merci mais que se passe t-il si les objets intégrer dans mon tableau n'ont pas de destructeur ?

Quand il n'y a pas de destructeur défini, le destructeur par defaut est appellé.

JC

Et que détruit le destructeur dans ce cas la ?

Il appelle le destructeur des données membres si elles en ont, et celui de la classe mère s'il y en a une.

... et donc si tu as des objets dont des membres sont des pointeurs sur des instances ( via new ), ce sont les pointeurs qui sont detruits par le constructeur par defaut, pas les objets instanciés --> mauvaise gestion mémoire --> toujours bien redefinir un destructeur (virtuel (cfr faq)). Je pense que tu trouveras des infos plus detaillées dans la FAQ.


A++

JC

Citation:

---

Code:

---

1 2	result = new TCompareResult(); tabResult[indexCombinaison] = * result;

---

---

Cette portion de code ne sert absolument à rien si ce n'est créer une fuite mémoire et réaliser une initialisation et une copie inutiles.

Pourquoi ce code génèrait une fuite mémoire ?
La je ne comprends pas, le code est propre non ?

Parce que la mémoire allouée par

Code:

---

result = new TCompareResult();

---

N'est plus référencée nulle part a priori, il est donc impossible de la libérer.

Citation:

---

le code est propre non ?

---

Oulah, non, loin de là.
C'est du grand n'importe quoi. Et faire du code propre, c'est quelques niveaux au dessus que de faire du code qui ait du sens.

La solution la plus propre est probablement

Code:

---

std::vector<TCompareResult> tabResult(nbCombinaison);

---

Citation:

---

Envoyé par loufoque

La solution la plus propre est probablement

Code:

---

std::vector<TCompareResult> tabResult(nbCombinaison);

---

---

ou

Code:

---

1 2 3 4

std::vector<TCompareResult> tabResult; tabResult.reserve(nbCombinaison);   tabResult.push_back(....)

---

ou utiliser une structure qui n'a pas besoin de stocker tout ca et agit sur chaque combinaison tour a tour.

Et si je fais un delete sur la variable result après son utilisation, le code reste impropre? Normalement la mémoire devrait être désallouée non ? je ne comprends pas.

Code:

---

1 2 3 4 5

if(result != NULL){ delete result; result = NULL; }

---

Ce code devrait être bon théoriquement non ?

Si tu veux dire que tu utilises:

Code:

---

1 2 3 4 5 6

result = new TCompareResult(); tabResult[indexCombinaison] = * result; if(result != NULL){ delete result; result = NULL; }

---

Ce code est correct en ce sens qu'il a le resultat auquel tu t'attends vraissemblablement, mais il n'est neanmoins pas bon du tout. Allouer de la memoire dynamique pour y construire un object avec le constructeur par defaut, copier cet objet et ensuite liberer la memoire dynamique est un abus certain de celle-ci.

Code:

---

tabResult[indexCombinaison] = TCompareResult();

---

(Accessoirement, delete est bien defini si l'argument est NULL).

Citation:

---

Envoyé par loufoque

Oulah, non, loin de là.
C'est du grand n'importe quoi. Et faire du code propre, c'est quelques niveaux au dessus que de faire du code qui ait du sens.

La solution la plus propre est probablement

Code:

---

std::vector<TCompareResult> tabResult(nbCombinaison);

---

---

:? pas très sympa...
surtout que ta solution peut coûter cher si TCompareResult est long à copier...
Faut connaitre le contexte avant de juger.

Citation:

---

surtout que ta solution peut coûter cher si TCompareResult est long à copier...

---

Où tu vois la moindre copie ?
Il n'y aura copie qu'avec des push_back ou autres redimensionnements.
Ou copie du vector lui-même, bien sûr.

Merci de toutes vos réponses, mais je ne comprends pas trop bien alors la notion d'allocation dynamique de mémoire.

Quelle est la différence entre:

Code:

---

1 2	TCompareResult * result = new TCompareResult();

---

et

Code:

---

1 2	TCompareResult result;

---

Dans les deux cas je peux utiliser les méthodes de mes classes. Seulement une fois j'utilise un point (result.test()) et l'autre fois j'utilise une fleche (result->test()).

Merci de m'éclaircir parce que la je ne comprends plus trop!

Dans un premier cas tu as un pointeur vers un objet dynamiquement alloué que tu dois libérer explicitement et dans le second cas tu as un objet alloué sur la pile.

et liberrer explicitement cela se traduit par un delete non ? Comme je l'ai montré précédemment!

Précédemment tu ne faisais que libérer une copie.

Donc j'ai suivi vos conseil pour parader ma fuite de mémoire! J'utilise les vector mais maintenant lorsque je veu supprimer son contenu, la mémoire allouée (gestionnaire des tâches) reste la même.

Voici ce que je fais:

Code:

---

1 2 3 4

//Création du vecteur tabResult.reserve(nbCombinaison); tabResult.push_back(TCompareResult());

---

Code:

---

1 2 3 4

//Suppression du vecteur et du contenu tabResult.erase(tabResult.begin(),tabResult.end()); tabResult.clear();

---

C'est normal.

Pourquoi c'est normal ?

Un vecteur ne désalloue jamais la mémoire allouée, c'est plus performant si tu fais plusieurs opérations dessus.

Si tu tiens réellement à ce que la mémoire allouée colle au nombre d'éléments, tu peux utiliser ce code :

Code:

---

std::vector<TCompareResult>(tabResult).swap(tabResult);

---

PS : le erase ne sert à rien juste avant un clear (c'est exactement ce que ce dernier fait).

Citation:

---

Envoyé par Pfeffer

Donc j'ai suivi vos conseil pour parader ma fuite de mémoire! J'utilise les vector mais maintenant lorsque je veu supprimer son contenu, la mémoire allouée (gestionnaire des tâches) reste la même.

---

Il y a au moins quatre niveaux d'allocation a considerer dans le cas present.

Tout d'abord, il y a la memoire allouee par l'OS au processus. C'est celle que te permet de regarder le gestionnaire des taches.

Ensuite il y a la memoire que ton programme a alloue et pas liberee. Ce n'est pas necessairement la meme chose, car le runtime pour repondre a une allocation que tu vas va demander a l'OS de la memoire, mais il peut en demander plus pour ne pas avoir a demander perpetuellement a l'OS d'une part, parce que l'OS a une granularite differente (l'OS alloue par page -- souvent 4 K, parfois plus -- ou par groupe de pages) d'autre part, finalement parce que la memoire que tu a liberee peux ne pas pouvoir etre rendue a l'OS meme si elle est de taille convenable (par exemple parce qu'elle ne se trouve pas au bon endroit).

Les deux autres niveaux sont propres aux conteneurs de la bibliotheque standard.

Ces conteneurs utilisent des allocateurs, qui peuvent jouer le meme jeux que l'allocateur du runtime: allouer plus que necesasire immediatement et ne pas rendre directement a l'allocateur du runtime.

Quatriemement, les conteneurs eux-meme peuvent ne pas rendre la memoire directement a l'allocateur (difference entre capacity() et size()).

Dans le cas present, clear() ne change pas le resultat de capacity(), donc on reste au quatrieme niveau. Il y a des bonnes chances que tu ne voies pas non plus de difference meme avec la technique donnee par Laurent, a cause des 3 autres niveaux.

Merci pour tous ses éléments de réponses mais maitenant comment est ce que je peux faire pour réduire cette fuite mémoire!

En fait mon process maintenant, grâce au vector, ne prends pas beaucoup de mémoire (dans le gestionnaire des tâches). Entre 100 000 ko et 400 000 ko pendant l'opération. Et 100 000 ko à la fin de l'opération.

Ceci dit au niveau de la chagre dédiée, l'évolution reste consante. 900 Mo à la fin de la deuxième opération.

Je dois donc avoir quand même des fuites mémoires!