difference entre clear() et swap()

Bonjour,

lorsque j'ai un conteneur (vector, set, map...), et que je veux le vider, j'ai pris l'habitude de faire un swap:

Code:

---

1 2 3 4 5

vector<int> mon_vecteur;   //... je remplis mon vecteur   vector<int>().swap( mon_vecteur ); // je vide le vecteur

---

Mais j'ai un doute soudain: quelle est la différence entre le swap ci-dessus et la fonction membre clear()?

ps: la seule "doc" aue j'arrive à trouver sur clear() est: "erase all the elements".

ps2: en fait, ce doute m'est venu parce que je dois optimiser un code et là je cherche à optimiser la moindre ligne.

Erase/remove trick pour enlever d'un conteneur.

swap trick pour libérer la mémoire. (ie le conteneur reste en mémoire en fait au cas où tu le reconstruises après.)

swap trick :
vector<int>(foo).swap(foo). ;)

Salut,

Je dirais que clear() ne libère pas la mémoire allouée alors que ton swap() va réinitialiser l'espace réservé à la valeur initiale.
Essaye de faire un capacity() après un clear()/swap( std::vector<...>() ) sur un vecteur avec pas mal d'éléments pour voir la différence ?

MAT.

Ouai enfin, j'ai dis erase remove, mais bon, pour le vider tu fais un clear. Sa libère les objets mais pas la mémoire associé au vecteur lui même, (optimisation apparemment).
Pour la libérer vraiment t'as le swap trick.


(avec les déboires du server je me suis trompé dans ce que j'ai posté ^^).

Salut,
La différence c'est que clear() ne désalloue pas la mémoire. Par exemple pour un vecteur, un clear est très rapide, il détruit les objets et set le pointeur de taille au début du tableau. (size = 0, capacité = inchangé)

L'équivalent C++0x du swap trick serait :

Code:

---

1 2 3

v.clear(); v.shrink_to_fit() // ajuste la capacité, donc ici désalloue entièrement.

---

Chez moi, la différence (en terme de perf) est nulle.

Citation:

---

Envoyé par Mat007

Salut,

Je dirais que clear() ne libère pas la mémoire allouée alors que ton swap() va réinitialiser l'espace réservé à la valeur initiale.
Essaye de faire un capacity() après un clear()/swap( std::vector<...>() ) sur un vecteur avec pas mal d'éléments pour voir la différence ?

MAT.

---

Oui c'est bien ça, tu as raison.

Citation:

---

Envoyé par JulienDuSud

Chez moi, la différence (en terme de perf) est nulle.

---

Chez moi il y a de grosses différences, tant en debug qu'en release. Teste avec le code suivant par ex.:

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91

#include <iostream> #include <algorithm> #include <vector> #include <string> #include <ostream>   #include "windows.h" // oué bon je sais... (mais j'ai pas boost d'installé là et je suis pressé :p )   using namespace std;   class PerfTimer { public: PerfTimer(); ~PerfTimer();   static bool Init() { LARGE_INTEGER proc_freq;   if ( !QueryPerformanceFrequency( &proc_freq ) ) return false;   frequency = 1.0 / proc_freq.QuadPart; return true; }   void Start() { QueryPerformanceCounter( &start ); }   double Stop() { QueryPerformanceCounter( &stop ); return ( ( stop.QuadPart - start.QuadPart ) * frequency ); }   void StopAndPrint( const std::string & message, std::ostream & ostr ); { double duracion = Stop(); ostr << message << duracion << " ms" << std::endl; }   private: static double frequency; LARGE_INTEGER start; LARGE_INTEGER stop; };   double PerfTimer::frequency = 0;   struct MyGenerate { MyGenerate():counter(0){} int operator () () { return counter++; } private: int counter; };   int main() { if ( !PerfTimer::Init() ) { cout << "error: problema en la inicializacion de PerfTimer" << endl; return EXIT_FAILURE; }   PerfTimer pt; vector<int> v( 500000 );   pt.Start(); generate( v.begin(), v.end(), MyGenerate() ); pt.StopAndPrint( "generate: ", cout );   pt.Start(); v.clear(); pt.StopAndPrint( "clear: ", cout );   cout << "cap: " << v.capacity() << endl;   vector<int> v1( 500000 ); generate( v1.begin(), v1.end(), MyGenerate() );   pt.Start(); vector<int>().swap( v1 ); pt.StopAndPrint( "swap: ", cout );   cout << "cap: " << v1.capacity() << endl;   cout << "end" << endl; cin.get(); return EXIT_SUCCESS; }

---

Non mais les perfs à gagné sont au niveau de l'occupation mémoire. Pas au niveau de la rapidité. Le swap trick met à 0 la capacity du vector, c'est comme ça que tu gagnes de la place.

Citation:

---

Envoyé par Goten

Le swap trick met à 0 la capacity du vector, c'est comme ça que tu gagnes de la place.

---

:koi:
Je pensais qu'il inversait (en gros) les buffers ce qui fait que mon_vecteur a un buffer vide et que le vecteur temporaire non nommé libère l'ancien buffer. La différence de temps doit être dans le delete[] globalement non ?

Ben il swap aussi la capacity, la capacity du temporaire étant à 0...

Et c'est ça le plus important la capacity. (c'est ça qui prend de la place en mémoire).

Citation:

---

Envoyé par Goten

Ben il swap aussi la capacity, la capacity du temporaire étant à 0...

Et c'est ça le plus important la capacity. (c'est ça qui prend de la place en mémoire).

---

En gros, MinGW :

Code:

---

1 2 3 4 5 6 7 8

std::vector::swap() { /*[...] */ std::swap(this->_M_impl._M_start, __x._M_impl._M_start); std::swap(this->_M_impl._M_finish, __x._M_impl._M_finish); std::swap(this->_M_impl._M_end_of_storage, __x._M_impl._M_end_of_storage); }

---

En gros, MS VCExpress 2008 :

Code:

---

1 2 3 4 5 6 7

std::vector::swap() { /*[...] */ std::swap(_Myfirst, _Right._Myfirst); std::swap(_Mylast, _Right._Mylast); std::swap(_Myend, _Right._Myend); }

---

capacity s'est à chaque fois XXXend - XXXfirst. J'ai quand même l'impression que l'important est bien le swap des buffers et le fait que le temporaire va faire un delete sur le buffer qu'on souhaite supprimer.

Oui mais quand tu fais :

std::vector<foo>().swap(myVec);

std::vector<foo>() <== crée un temporaire avec une capacity de 0, donc XXXend = XXXfirst = 0;

Là c'est pour supprimer tout, prend un exemple plus concret, t'as un vec (myVec) de 50000 éléments, ton vector tombe à 500 éléments suite à des erase / remove, alors tu fais un :

std::vector<foo>(myVec).swap(myVec);

Sa va construire un temporaire qui sera une copie de myVec mais capacity sera construit depuis 0 et donc adapté à sa nouvelle taille, puisque le copy ctor fait un uninitialized_copy (). (ie 500, exactement 500 ou pas je sais pas). Puis on swap le tout sur myVec existant.
Tu gagnes donc _M_end_of_storage - _M_last

Citation:

---

Envoyé par r0d

Chez moi il y a de grosses différences, tant en debug qu'en release.

---

Alors vu que je suis pas sous windows, ce code, chez moi:

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82

#include <iostream> #include <algorithm> #include <vector> #include <string> #include <ostream>   #include <time.h>   struct PerfTimer { struct GetTimeFailure{};   timespec start;   PerfTimer() { restart(); }   void restart() { start = getTime(); }   double elapsed() { timespec now = getTime(); return (now.tv_nsec - start.tv_nsec) / 1000000.0; // nano to ms }   timespec getTime() { timespec ret; if( clock_gettime( CLOCK_REALTIME, &ret ) == -1 ) throw GetTimeFailure(); return ret; } };   struct MyGenerate { MyGenerate():counter(0){} int operator () () { return counter++; } private: int counter; };   using namespace std;   int main() { PerfTimer t;   double sum = 0;   vector<int> v(5000000);   for( int i = 0; i < 1000000; ++i ) { generate( v.begin(), v.end(), MyGenerate() ); t.restart(); v.clear(); sum += t.elapsed();   }   cout << "clear within " << sum << "ms." << endl;   sum = 0;   for( int i = 0; i < 1000000; ++i ) { generate( v.begin(), v.end(), MyGenerate() ); t.restart(); vector<int>().swap( v ); sum += t.elapsed(); }   cout << "swap within " << sum << "ms." << endl;   cin.get(); return EXIT_SUCCESS; }

---

donne

Citation:

---

clear within 55.044ms.
swap within 56.4456ms.

---

Avec -O3, bien sûr.

edit: je viens de lancer 1000 tests d'affilés (dans le code, pas en externe), et j'obtiens ça:

Citation:

---

clear averages 19.3602ms.
swap averages 19.407ms.

---

Donc c'est vraiment pareil au niveau du temps mis "par instruction". Par contre, l'un libère la mémoire l'autre pas. Tout dépend de ce que tu veux faire, donc. Si tu comptes réinsérer des éléments par la suite, clear() est mieux. Si t'as besoin d'espace tout de suite (gros gros vector sur une petite machine), swap est le mieux.

Je rejoins donc goten.

Comme je l'ai dit. Le but du swap trick est de sauver de la mémoire pas du temps processus.

Citation:

---

Envoyé par JulienDuSud

Alors vu que je suis pas sous windows, ce code, chez moi:

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82

#include <iostream> #include <algorithm> #include <vector> #include <string> #include <ostream>   #include <time.h>   struct PerfTimer { struct GetTimeFailure{};   timespec start;   PerfTimer() { restart(); }   void restart() { start = getTime(); }   double elapsed() { timespec now = getTime(); return (now.tv_nsec - start.tv_nsec) / 1000000.0; // nano to ms }   timespec getTime() { timespec ret; if( clock_gettime( CLOCK_REALTIME, &ret ) == -1 ) throw GetTimeFailure(); return ret; } };   struct MyGenerate { MyGenerate():counter(0){} int operator () () { return counter++; } private: int counter; };   using namespace std;   int main() { PerfTimer t;   double sum = 0;   vector<int> v(5000000);   for( int i = 0; i < 1000000; ++i ) { generate( v.begin(), v.end(), MyGenerate() ); t.restart(); v.clear(); sum += t.elapsed();   }   cout << "clear within " << sum << "ms." << endl;   sum = 0;   for( int i = 0; i < 1000000; ++i ) { generate( v.begin(), v.end(), MyGenerate() ); t.restart(); vector<int>().swap( v ); sum += t.elapsed(); }   cout << "swap within " << sum << "ms." << endl;   cin.get(); return EXIT_SUCCESS; }

---

donne


Avec -O3, bien sûr.

edit: je viens de lancer 1000 tests d'affilés (dans le code, pas en externe), et j'obtiens ça:



Donc c'est vraiment pareil au niveau du temps mis "par instruction". Par contre, l'un libère la mémoire l'autre pas. Tout dépend de ce que tu veux faire, donc. Si tu comptes réinsérer des éléments par la suite, clear() est mieux. Si t'as besoin d'espace tout de suite (gros gros vector sur une petite machine), swap est le mieux.

Je rejoins donc goten.

---

Je ne souhaite pas me montrer excessivement cruel, mais ton code ne fait pas grand chose, étant donné que

1) le vecteur est créé en dehors de toute boucle, ce qui fait que après le second clear ne change pas l'état du vecteur : puis v.begin() == v.end().

2) idem, ce qui fait qu'une fois le premier swap effectué, le vecteur est cette fois complètement vide : v.begin() == v.end() = NULL ; donc aucune deallocation n'aura lieu après.

C'est donc assez normal que tu ait les même resultats.

Je rajoute les lignes v.resize() qui vont bien, le code devient :

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87

#include <iostream> #include <algorithm> #include <vector> #include <string> #include <ostream>   #include <time.h>   struct PerfTimer { struct GetTimeFailure{};   timespec start;   PerfTimer() { restart(); }   void restart() { start = getTime(); }   double elapsed() { timespec now = getTime(); return (now.tv_nsec - start.tv_nsec) / 1000000.0; // nano to ms }   timespec getTime() { timespec ret; if( clock_gettime( CLOCK_REALTIME, &ret ) == -1 ) throw GetTimeFailure(); return ret; } };   struct MyGenerate { MyGenerate():counter(0){} int operator () () { return counter++; } private: int counter; };   using namespace std;   int main() { PerfTimer t;   double sum = 0;   // bloc, histoire de contrôler la destruction de v { vector<int> v;   for( int i = 0; i < 100000; ++i ) { v.resize(10000); generate( v.begin(), v.end(), MyGenerate() ); t.restart(); v.clear(); sum += t.elapsed(); } }   cout << "clear within " << sum << "ms." << endl;   sum = 0;   // bloc, histoire de contrôler la destruction de v { vector<int> v;   for( int i = 0; i < 100000; ++i ) { v.resize(10000); generate( v.begin(), v.end(), MyGenerate() ); t.restart(); vector<int>().swap( v ); sum += t.elapsed(); } } cout << "swap within " << sum << "ms." << endl; }

---

La ligne de commande :

$> g++ -O3 -o swaptrick swaptrick.cpp -lrt

Le résultat :

clear within 196.558ms.
swap within 205.515ms.

Il y a clairement une différence, mais vu le nombre d'itérations, ça n'est pas vraiment clairement significatif. A noter que dans le premier cas, le v.resize() n'est pas censé avoir d'effet, puisque la capacité ne change pas. Dans le second cas, v.resize() a besoin de faire une allocation, ce qui peut être une perte de temps supplémentaire dans certains contextes...

Il y a tout de même quelque chose de bizzarre dans cette histoire, parce que j'ai testé le code que j'ai posté ci-dessus sur plusieurs machines, et à chaque fois j'obtiens des résultats fort différents... là par exemple, j'ai:

Citation:

---

generate: 0.107798 ms
clear: 1.10955e-006 ms
cap: 50000000
generate 2: 0.107292 ms
swap: 0.0103587 ms
cap: 0
end

---

Ce qui signifie que le clear() est environ 10000 fois plus rapide que le swap :calim2:
des fois c'est l'inverse... et des fois c'est pareil :?

comprends pô :koi:

Citation:

---

Envoyé par Emmanuel Deloget

Je ne souhaite pas me montrer excessivement cruel, mais ton code ne fait pas grand chose, étant donné que

1) le vecteur est créé en dehors de toute boucle, ce qui fait que après le second clear ne change pas l'état du vecteur : puis v.begin() == v.end().

2) idem, ce qui fait qu'une fois le premier swap effectué, le vecteur est cette fois complètement vide : v.begin() == v.end() = NULL ; donc aucune deallocation n'aura lieu après.

C'est donc assez normal que tu ait les même resultats.

---

Oui, tu as raison :aie:.

Citation:

---

A noter que dans le premier cas, le v.resize() n'est pas censé avoir d'effet, puisque la capacité ne change pas. Dans le second cas, v.resize() a besoin de faire une allocation, ce qui peut être une perte de temps supplémentaire dans certains contextes...

---

dans ce cas-ci, ça ne devrait pas influencer sur les mesures vu qu'on mesure pas le temps d'allocation, juste le temps qu'il faut pour vider.

Mes valeures sont plutôt fixes:

Citation:

---

clear within 4.2654ms.
swap within 7.72939ms.

---

La différence de vitesse c'est celle de la désallocation, prenons ce code suivant:

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

#include <iostream> #include <algorithm> #include <vector> #include <string> #include <ostream>   #include <time.h>   struct PerfTimer { struct GetTimeFailure{};   timespec start;   PerfTimer() { restart(); }   void restart() { start = getTime(); }   double elapsed() { timespec now = getTime(); return (now.tv_nsec - start.tv_nsec) / 1000000.0; // nano to ms }   timespec getTime() { timespec ret; if( clock_gettime( CLOCK_REALTIME, &ret ) == -1 ) throw GetTimeFailure(); return ret; } };   struct A { ~A() { std::cout << "destruction" << std::endl; } };   struct MyGenerate { MyGenerate(){} A operator () () { return A(); } private: //int counter; };   using namespace std;   int main() { PerfTimer t;   double sum = 0;   sum = 0;   // bloc, histoire de contrôler la destruction de v { for( int i = 0; i < 10; ++i ) { vector<A> v; v.resize(5); generate( v.begin(), v.end(), MyGenerate() ); t.restart(); cout << "hi" << endl; vector<A>().swap( v ); cout << "ha" << endl; sum += t.elapsed(); } }   cout << "swap within " << sum << "ms." << endl;   }

---

Il y a désallocation entre t.restart() et t.elapsed(), donc c'est normal qu'il y ait une différence de temps (clear ne désalloue pas).

Euh ...
Je vais avoir l'air idiot (sûrement :aie: ), mais pourquoi v.clear() remet-il à zéro tout ? Pourquoi ne fait-il pas simplement XXXlast = XXXbegin ? Ca améliorerait les performances, non ?

Citation:

---

Envoyé par r0d

Il y a tout de même quelque chose de bizzarre dans cette histoire, parce que j'ai testé le code que j'ai posté ci-dessus sur plusieurs machines, et à chaque fois j'obtiens des résultats fort différents... là par exemple, j'ai:
Ce qui signifie que le clear() est environ 10000 fois plus rapide que le swap :calim2:
des fois c'est l'inverse... et des fois c'est pareil :?

comprends pô :koi:

---

Ben, même si la version swap force à rappeler le pooler de vector, tu ne contourne en rien le pooler global. De plus, ce code est un affreux paradoxe : d'un côté perte d'efficacité à cause du rappelle de fonction, de l'autre perte d'efficacité du à un nombre incalculable de cache fault ><...

Citation:

---

Envoyé par Lenoa

Euh ...
Je vais avoir l'air idiot (sûrement :aie: ), mais pourquoi v.clear() remet-il à zéro tout ? Pourquoi ne fait-il pas simplement XXXlast = XXXbegin ? Ca améliorerait les performances, non ?

---

Ca porte un nom : Le LLTINT (Leak Like There Is No Tomorow) Principle. Je sais pas pourquoi, mais c'est généralement peu apprécié -_-'.

C'est peu apprécié ?
Au vu du smiley, je sens que j'ai bel et bien l'air idiot, mais bon ... :calim2:
Laisser des objets dans une zone non utilisée n'est pas un gain de temps ? De toute façon, où est l'intérêt de r.a.z la mémoire ? La complexité de clear() passerait de O(N) à O(1) ... ? C'est comme le new (ou le calloc) qui r-a-z la mémoire. Pourquoi une alloc en O(N) et pas en O(1) ? (sans compter le temps système.) Pourquoi l'OS r-a-z la mémoire avant que new/calloc ne le refasse ? (cf. le comportement de malloc, pour lequel rien n'est spécifié sur les données)
Que de questions :aie:

Cf. Le principe que je viens d'évoquer. En gros, il y a des cas ou oui, il est plus intéressant de faire leaké du code... Pour de la programmation kernel, c'est invraisemblable, pour de l'applicatif, ça dépend. Et encore, c'est sans compter sur les poolers, et la perte de perf du au cache-fault.

Après, il font compté aussi sur les poolers, rendant moins lourdes les opérations d'allocation et de désallocations. Heureusement que il temporisent un peu les demande à l'OS...

Ensuite, le temps gagné en évitant les cache-faults et presque aussi long que le temps perdu en désalocation/reallocation... Et le meilleur moyen de les éviter reste encore de grouper la mémoire, donc de la désallouer le plus souvent possible.

Au final, le LLTINT et généralement préférable quand il n'y a effectivement pas de lendemain...

D'ailleurs, suite à ta remarque et à ton "incontinence" mémoire, je te conseil de tester les codes suivants :

Code:

---

1 2 3

for(int i=0; i<1000000; ++i) char* ptr = new char[10];

---

et

Code:

---

1 2 3 4 5

for(int i=0; i<1000000; ++i) { char* ptr = new char[10]; delete [] ptr; }

---

Après, faire un calloc alors qu'on en a pas besoin, c'est stupide, c'est vrai.

A la question : pourquoi l'OS met la mémoire à 0 ? J'aurais dit pour des raisons de sécurité, mais je ne suis pas spécialiste.

Citation:

---

Envoyé par Lenoa

Laisser des objets dans une zone non utilisée n'est pas un gain de temps ?

---

Ca dépend de quels objets on parle. S'il s'agit d'entiers, pourquoi pas. Mais maintenant, s'il s'agit de données qui on un pointeurs vers une grosse zone de mémoire, sans libérer ces objets, cette mémoire annexe ne serait pas libérée. Si ces objets maintiennent ouvert un fichier, ces fichiers ne seront pas fermés...

En gros, si les objets ont un destructeur, il vaut mieux appeler ce dernier quand on fait clear. Certaines personnes ont proposer de détecter ce genre de situation à la compilation, pour faire des raccourcis dans la gestion d'objets n'ayant pas de destructeur.

@Lavock: Tu parles bien de la même chose que moi là ? Parce que en fait c'est juste laisser des objets "non pointés", c'est-à-dire pointés mais dont la valeur n'est plus accessible, et qui vont bien être détruits. Du coup, ton exemple ne marche pas :mouarf: (enfin une victoire :lol: )

@JolyLoic: Alors faire deux versions (template et spécialisée types de base) ?
Exemple (beaucoup simplifié :zoubi: ) :

Code:

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65

template<typename T> class vector_base { protected: T* begin_, last_, end_; public: ~vector_base() { delete_(begin_, last_); /* detruit de begin_ a last_ */ } // ... }; template<typename T> class vector_deleting : private vector_base<T> { public: using vector_base; // Pas sur void clear() { while(last_ != begin_) { --last_; delete last_; } delete begin_; // OU delete last_ } };   template<typename T> class vector_not_deleting : private vector_base<T> { public: using vector_base; // Pas sur void clear() { last_ = begin_; } };   template<typename T> class vector : private vector_deleting { public: using vector_deleting; // Pas sur ... }; class vector<short> : private vector_not_deleting { public: using vector_not_deleting; // Pas sur ... }; class vector<unsigned short> : private vector_not_deleting { public: using vector_not_deleting; // Pas sur ... }; class vector<int> : private vector_not_deleting { public: using vector_not_deleting; // Pas sur ... }; class vector<unsigned int> : private vector_not_deleting { public: using vector_not_deleting; // Pas sur ... }; class vector<long> : private vector_not_deleting { public: using vector_not_deleting; // Pas sur ... }; // ...

---

Hum, je me disais bien que j'avais louper quelque chose...
...
...
+1 >< !

[edit]

Citation:

---

Envoyé par Lenoa

@Lavock: Tu parles bien de la même chose que moi là ? ... enfin une victoire

---

=> M'enfin ta pas relever lorsque je parlais de leak au début :P !

Message 1 : +1 à qui ? Et j'avais pas fait gaffe au mot leak :bug:
Message 2 : Je n'ai montré qu'un code très (très (très (très (très)))) grossier :mrgreen:

Jolyloic. J'ai "posté" en même temps que toi.

Oui, d'ailleur j'ai supprimé le message... So-useless je me suis dit >< !

Lenoa, la lib c++ de VS2008 fait déjà ce que tu proposes.
vector::clear() est implémentée sous la forme :

Code:

---

1 2 3 4 5

void clear() { // erase all erase(begin(), end()); }

---

Avec erase :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

iterator erase(const_iterator _First_arg, const_iterator _Last_arg) { // erase [_First, _Last) iterator _First = _Make_iter(_First_arg); iterator _Last = _Make_iter(_Last_arg);   if (_First != _Last) { _Destroy(_Ptr, _Mylast); _Mylast = _Ptr; } }

---

Destroy possède deux versions, une pour les types de base (int, double...) qui ne fait rien :

Code:

---

1 2 3 4 5 6 7

template<class _Alloc> inline void _Destroy_range(typename _Alloc::pointer _First, typename _Alloc::pointer _Last, _Alloc& _Al, _Scalar_ptr_iterator_tag) { // destroy [_First, _Last), scalar type (do nothing) }

---

Et une deuxième pour tous les autres types, qui appelle le destructeur de chaque objet du conteneur.

Code:

---

1 2 3 4 5 6 7 8 9

template<class _Alloc> inline void _Destroy_range(typename _Alloc::pointer _First, typename _Alloc::pointer _Last, _Alloc& _Al, _Nonscalar_ptr_iterator_tag) { // destroy [_First, _Last), arbitrary type for (; _First != _Last; ++_First) _Al.destroy(_First); }

---

@Lavock: On est d'accord 8-)
@Arzar: Bien, mais pourquoi c'est pas dans la norme ? C'est çà que je demande :zoubi:

C'est une question de qualité d'implémentation. Ne pas forcer tous les gens à le faire, mais le permettre quand même, pour les gens qui ont envie de faire un effort supplémentaire.