Discussion :

[TNT89]

Bonjour,

Voilà, j'ai un petit [/gros] problème avec un std::vector. Bon un peu de code serait mieux que de long discours :

Pour les objets utilisés dans le vecteur :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
template <typename TYPE, int n>
    struct VECT
    {
        TYPE data[n];
        static const int size = n;
 
        VECT<TYPE, n>(void) { return ;}
 
        VECT<TYPE, n>(const VECT<TYPE, n>& v)
        {
            for(int i = 0; i<n; i++)
                data[i] = v.data[i];
        }
 
        ~VECT<TYPE, n>(void)
        {
            //Signal de destruction
        }
 
        inline
        TYPE& operator[] (int i)
        {
            return data[i];
        }
 
        inline
        VECT<TYPE, n>& operator= (const VECT& v)
        {
            for(int i = 0; i<n; i++)
                data[i] = v.data[i];
            return (*this);
        }
    };

Déclaration du-dit vecteur (dans une classe):

Code :

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

1
2
 
std::vector< VECT<unsigned char, 3> > visibles;

On ajoute un élément : (dans une boucle for)

Code :

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

1
2
3
4
5
6
 
VECT< unsigned char, 3> v;
v[0] = 1;
v[1] = 1;
v[2] = 1;
visibles->push_back( v );

à l'ajout : le vecteur augmente bien le nombre d'élément contenus mais appelle le destructeur pour chaque élément contenu (donc plusieurs destructions par objet insérés pendant les tours de boucle...).

Bref que du bonheur... et des fuites mémoires...
A noter que sans aucune opérations, si le vecteur est simplement déclaré, il y a aussi des erreurs. J'ai essayé d'utiliser un pointeur vers vecteur alloué avec new, cela supprime ce dernier bug mais les éléments continuent à être détruits...

Merci de vos conseils...

[loufoque]

visibles n'est pas un pointeur. Tu ne peux pas utiliser l'opérateur ->.
Il n'y a aucun problème dans le reste du code.

Fournis un exemple minimal, en un seul fichier, qui compile et qui démontre le problème.

[JolyLoic]

à l'ajout : le vecteur augmente bien le nombre d'élément contenus mais appelle le destructeur pour chaque élément contenu (donc plusieurs destructions par objet insérés pendant les tours de boucle...).

J'ai pas trop lu ton code, mais peut-être que j'ai un élément de réponse. Il faut savoir que push_back, comme toutes les autres fonctions de vector, met dans le vecteur non pas l'objet qui lui est passé en paramètre, mais une copie de celui-ci. Il est donc normal que l'objet lui même soit détruit.

[Klaim]

Paril que JolyLoic, j'imagine que plus tu feras de push_back moins t'auras d'appel aux destructeurs d'ailleurs (parceuq'il réalloue le double de ce qu'il avait alloué avant quand il n'y a plus de place et que tu fais un push_back).

[furyman]

Tu as tous les éléments, reste à regrouper les pièces du puzzle:

1. En passant des objets à la fonction push_back, tu déclenches une copie de l'objet passé, qui lui est stocké, et pour peu que l'objet passé soit local à la boucle dont tu parles, il est détruit à la fin de la portée (la boucle en l'occurence).

2. En n'allouant pas de taille initiale à visibles, c'est 0 qui lui est assigné. Pour le premier push_back, une allocation est réalisée mais aucun élément n'étant présent avant le premier push_back, la réallocation ne détruit aucun objet temporaire (donc pas de destruction supplémentaire lors de la première itération de boucle)

3. Lors des autres itérations, la taille passe à 1, puis 2, 3, 4, 6, etc ce qui fait que lors de chaque réallocation, des objets temporaires seront détruits dans la fonction push_back (mais les réallocations n'interviennent pas à chaque tour de boucle)

4. je ne pense pas qu'il y ait de memory leak et la raison pour laquelle on conseille de stocker des pointeurs ou des valeurs dans les conteneurs est clairement illustrée ici: on a construction et destruction d'objet lors des insertions (push_back) ce qui implique des pertes de perf mais potentiellement des soucis mémoire si à la construction des objets des membres sont alloués dynamiquement (et si on ne fournit pas de constructeurs de copie par exemple)

[screetch]

il n y a pas de fuite memoire puisque tu n'appelles ni new ni malloc...