std::vector::clear() dans le constructeur et le destructeur

À partir du son de choses, les personnes qui ont écrit ce code ont été ceux qui ont raté quelque chose. Le seul moment où il serait judicieux d'appeler clear() dans un ctor ou dtor serait au milieu d'un autre code. Par exemple, un ctor peut lire dans certains de données, les traiter, puis de lire davantage de données. Dans un tel cas, il est probablement plus rapide à utiliser qu'un seul conteneur pour les données comme vous le lire, et d'effacer à chaque fois, plutôt que d'en créer un nouveau conteneur de chaque itération.

OriginalL'auteur Jerry Coffin

1. C'est COMPLÈTEMENT unnessecary pour effacer le contenu d'un conteneur stl dans un constructeur
2. C'est unnessecary pour effacer le contenu d'un conteneur stl dans un destructeur SAUF le conteneur contient un pointeur. Si le pointeur a été créé à l'aide de nouveau, il doit encore être supprimé premier. Après cela, il ne sera toujours pas nessecary .claire le conteneur.

Considérez ceci :

#define BOOST_TEST_MODULE StlContainers
#define BOOST_LIB_DIAGNOSTIC
#include <boost/test/unit_test.hpp>
#include <boost/assign.hpp>
#include <boost/assign/list_of.hpp>
#include <boost/assign/std/vector.hpp>
#include <vector>
using namespace boost::assign;
using namespace std;
const vector<int> my_ints_vector = list_of(0)(1)(1)(2)(3)(5)(8)(13)(21)(34);
struct ScopedStruct1
{
ScopedStruct1(const vector<int> & v) : m_v(v) {}
~ScopedStruct1() {}
private :
vector<int> m_v;
};
class A 
{ 
public :
A(int i) : m_i(i) {}
~A() {}
private :
int m_i;
};
struct ScopedStruct2
{
ScopedStruct2() {}
~ScopedStruct2() { for(vector<A*>::iterator it = m_v.begin(); it != m_v.end(); ++it) delete *it; }
vector<A*> m_v;
};
struct ScopedStruct3
{
ScopedStruct3() {}
~ScopedStruct3() { /* no deletion */ }
vector<A*> m_v;
};
BOOST_AUTO_TEST_CASE(StlContainer_storing_something_simple)
{
ScopedStruct1 str(my_ints_vector);
}
BOOST_AUTO_TEST_CASE(StlContainer_storing_pointers_with_delete)
{
ScopedStruct2 str;
for(int i = 0; i < 10; i++)
str.m_v.push_back(new A(i));
}
BOOST_AUTO_TEST_CASE(StlContainer_storing_pointers_without_delete)
{
ScopedStruct3 str;
for(int i = 0; i < 10; i++)
str.m_v.push_back(new A(i));
}

À l'aide de boost unit_test cadre que j'ai créé 3 cas de test. Le unit_test cadre est grand parce qu'il suit les fuites de mémoire.
Vous remarquerez que le 1er et le 2ème cas de test ne génèrent pas de fuites de mémoire, mais le 3ème cas n'parce que le vecteur de contenu ne sont pas supprimés.

OriginalL'auteur Maciek

Le seul cas que je peux penser de l'endroit où il serait utile est l'endroit où l'ordre de destruction des questions et le destructeur veut s'assurer que les objets dans le vecteur sont détruits avant que quelque chose d'autre.

Bien sûr, il est préférable de structure de code pour ne pas exiger que; toutefois, il est concevable que de raison.

OriginalL'auteur janm

Bien sûr, on doit appeler clear() ou redimensionner(0) ou l'équivalent de dire (std::_Destroy_range(...) dans le destructeur avant de le libérer.

De libération de la mémoire est faite par l'intermédiaire de l'allocateur::désallouer qui ne s'exécutent PAS les destructeurs. Il a juste libère la mémoire.

clear() est équivalent à redimensionner(0) qui exécute des destructeurs sur la première taille() des choses dans la mémoire tampon allouée

PAS seulement affecté les pointeurs, les descripteurs de fichiers, tenue mutex, toutes les autres ressources récupérables détenus par l'objet. Les destructeurs DOIT être exécuté. Avant l'instanciation du modèle ne sait pas que le destructeur est trivial. Si le destructeur est trivial, ALORS c'est optimisée APRÈS l'instanciation

OriginalL'auteur pgast