Utilisation de la class std::vector est très lourde!

Bonjour,
J'ai écrit un code c++ ou j'utilise des fonction qui retournent et reçoivent des tableau uni et bidimentionnelle, j'ai utilisé pour cela les opérateur new et delete[] et là j'ai rencontré le pb de fuites de memoire que j'ai pas pu detecter ; alors j'ai fait recour à la class std::vector et là j'ai pas rencontrer le pb des fuites de mémoire mais le temps d'éxécution est augmenter d'une façon très considérable dans le premier cas j'ai eu 591000 millisecondes et dans le deuxième 6.214e+006 millisecondes, je vous donne un exemple d'une fonction qui reçoit une matrice 'a' et un tableau 'b' en paramètre et retourne la sous matrice de 'a' dont les colonnes sont spécéfié dans b.
Utilisation de l'allocation dynamique:

Code:

---

1 2 3 4 5 6 7 8 9 10 11

double * sous_matrice(double * a,int *b, int m, int e,int l) { double *cl = new double[m * e]; int i,j; for(i=0;i<m;i++) for(j=0;j<e;j++) { cl[i*e+j]=a[i*l+b[j]]; } return(cl); }

---

Utilisation de la classe std::vector

Code:

---

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

typedef vector<double> Vec; typedef vector<int> VecInt; typedef vector<vector<double>> mat; mat sous_matrice(mat & a,VecInt & b, int m, int e,int l) { mat cl(m,vector<double>(e)); int i,j; for(i=0;i<m;i++) for(j=0;j<e;j++) { cl[i][j]=a[i][b[j]]; } return(cl); }

---

Alors je sais pas est ce que le problème est dans l'utilisation de la class std::vector; ou l'allocation dynamique est meilleur que cette dernière dans le temps d'éxécution et là je doit detecter ou sont les fuites de mémoire???

Bonjour

(message avant ton edit) 0. Utilise la balise [CODE] pour présenter du code

(message avant ton edit, la fin est toujours valide) 1. Lorsqu'on on demande à comparer deux codes, on met ces deux codes dans des balises [CODE] différentes et on fait en sorte que chaque code ait un main() et qu'il compile (pour pouvoir reproduire le problème facilement).

2. Lorsqu'on pose une question sur du temps d'exécution, on précise les options de compilation (utilises-tu bien -O3 ?)

3. Quelle sont les tailles choisies ? Que vaut m et e ?

4. C'est injuste, tu ne ne compares pas la même chose. Lorsque tu utilises le tableau "à la C", tu fais un accès linérisé; mais pas avec std::vector. Tu peux t'inspirer de la classe vector2D pour avoir un accès linérisé : lien vers le post avec la classe vector2D

5. Si le compilateur ne fait pas d'optimisation, tu copies un std::vector qui est plus long que de copier un pointeur. Le compilateur devrait optimiser pour supprimer la copie. Pour être sur de ne pas faire de copie, on pourrait passer le std::vector en référence ou utiliser la move semantic de C++11.

6. Pour le souci, des fuites mémoires :
- il faut utiliser std::vector ;)
- pour les régler, tout new doit avoir son delete (et tout new [] doit avoir son delete []) il manque donc un delete [] cl; cl = nullptr; // cl = 0; si avant C++11 (la régle est celui qui alloue est celui qui détruit)

1-OK, en ce qui concerne les balise je vais en tenir compte prochainement, ce qui est de main(): ce que j'ai donné n'est qu'une fonction, le code est encore plus long et je fait appel à cette fonction dans d'autre fonctions. Comment j'ai comparer: J'ai deux projet dans le premier j'utilise l'allocation dynamique (new et delete[])et dans le deuxième la class std::vector. J'ai exacuter le premier puis le deuxième dans le meme laptop avec une instance de 30 objet et les temps d'exacution sont 591000 millisecondes et 6.214e+006 millisecondes respecivement. Dans le premier projet j'avait des fuites de mémoire et avec 40 objet le programme ne termine pas l'éxacution (break leak of memory) et le deuxième projet à pris 24 heur.
2-Pour les options de compilation je comprend pas exactement ce que vous voulez dire par 'O3'
3-m=3 et e varie de 10 jusqu'à 50 de meme pour l dans le premier projet et avec l=40 j'avait fuites de mémoire et le programme n'a pas pu continuer l'exacution
4- je passe toujours la variable vector par référence, si le compilateur fait d'optimisation là je sais pas je vais chercher
5- pour les fuites mémoire j'ai refait mon code avec la class std::vector -ce qui fait le projet 2- pour eviter les fuites de mémoire et là il ya pas ce pb mais l'éxécution est devenu très lente c'est pour cette raison que je vous ai écrit. pour le delete [] je l'utilise après chaque appelle de la fonction sous_matrice dans le premier projet (dans le deuxième c'est pas la peine parceque la deallocation ce fait automatiuqement) et j'ai toujours des fuite de mémoire.
Ma question: est ce que le pb est dans la façon dans laquel j'ai utiliser la class std::vector??

Citation:

---

Envoyé par mathro

1-OK, en ce qui concerne les balise je vais en tenir compte prochainement, ce qui est de main(): ce que j'ai donné n'est qu'une fonction, le code est encore plus long et je fait appel à cette fonction dans d'autre fonctions.

---

Bien et n'hésite pas à plus aérer ton texte avec la touche «Entrée».
Tu peux faire un main articiel tel quel:

Code:

---

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

int main() { for (std::size_t nb_run = 0; nb_run <= 1000; ++nb_run) { for (std::size_t e = 10; e <= 50; ++e) { // Création de ta matrice // Appel à ta fonction } }   return 0; }

---

Citation:

---

Envoyé par mathro

2-Pour les options de compilation je comprend pas exactement ce que vous voulez dire par 'O3'

---

L'option de compilation -O3 va demander au compilateur d'optimiser le programme au plus haut au niveau d'optimisation. Cette option est "indispensable" avant de vouloir optimiser un programme.
GCC - Options That Control Optimization

Citation:

---

Envoyé par mathro

4- je passe toujours la variable vector par référence, si le compilateur fait d'optimisation là je sais pas je vais chercher

---

Je parle du return cl; de la fonction.

Citation:

---

Envoyé par mathro

5- pour les fuites mémoire j'ai refait mon code avec la class std::vector -ce qui fait le projet 2- pour eviter les fuites de mémoire et là il ya pas ce pb mais l'éxécution est devenu très lente c'est pour cette raison que je vous ai écrit. pour le delete [] je l'utilise après chaque appelle de la fonction sous_matrice dans le premier projet (dans le deuxième c'est pas la peine parceque la deallocation ce fait automatiuqement) et j'ai toujours des fuite de mémoire.

---

Tu as utiliser ma classe vector2D ?

Citation:

---

Envoyé par mathro

Ma question: est ce que le pb est dans la façon dans laquel j'ai utiliser la class std::vector??

---

Il faut compiler avec l'option -O3. Ensuite, il est préférable d'utiliser un vector linéarisé (comme dans ma classe vector2D). On peut aussi éviter la copie du return.

Bonjour,

ton utilisation de vector n'est pas correcte et pas du tout semblable à tes tableaux.
Pourquoi faire un vector de vector alors que tu n'utilises pas un tableau de tableau ?
Les opérations de push_back sont les "plus lentes" s'il y a réallocation mémoire.

Une bonne utilisation de vector utilisera un reserve préalable avant d'insérer les données.
Une bonne pratique est aussi d'utiliser un vector unidimensionnel.

En respectant ça, ce qui donne en plus un code semblable à ton code originel, tu obtiens

Code:

---

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

std::vector<double> sous_matrice(double * a,int *b, int m, int e,int l) { std::vector<double> cl; cl.reserve(m*e); int i,j; for(i=0;i<m;i++) for(j=0;j<e;j++) { cl[i*e+j]=a[i*l+b[j]]; } return(cl); }

---

Puisque tu fais un retour par copie, il pourrait également être plus intéressant de passer le vector en paramètre out de la méthode à la place.

Citation:

---

pour les régler, tout new doit avoir son delete (et tout new [] doit avoir son delete []) il manque donc un delete [] cl; cl = nullptr; // cl = 0; si avant C++11 (la régle est celui qui alloue est celui qui détruit)

---

La règle est uniquement qu'à tout new doit correspondre un delete. Il n'y a aucune obligation que celui qui réalise l'allocation doive faire la libération. Dieu merci, sinon on serait bien limité... Les problèmes de responsabilité ne se posent pas par hasard.
Et libérer cl avant de le retourner c'est le meilleur moyen de faire une fonction qui ne réalise rien.

Ok. Déjà merci beaucoup pour vos réponses :ccool:

Je travail avec visual studio 2010 et j'arrive pas à trouver l'option de compilation o3, mais il ya d'autre façon d'optimiser la compilation, Je vais aller regarder ça de plus près et me creuser un peu la tête, en meme temps j'essayerai d'inclure votre class vector2D.je reviens vers vous une fois ça marche

http://stackoverflow.com/questions/8...r-optimization

Bousk merci beaucoup pour votre réponse.
En effet je suis entrain d'utiliser un tableau de tableau vous voyez bien que j'utilise dans le deuxième code

Code:

---

cl[i][j]=a[i][b[j]];

---

Mais apparament votre code résout exactement mon problème: pas de fuites de mémoire d'une part et permet l'utilisation d'un tableau unidementionnelle ce qui permet d'optimiser le temps d'éxécution, c'est ce que j'ai besoin exactement. Merci infiniment :ccool:

Citation:

---

Puisque tu fais un retour par copie, il pourrait également être plus intéressant de passer le vector en paramètre out de la méthode à la place.

---

Je comprend pas exactement ce que vous voulez dire

Citation:

---

Envoyé par Bousk

La règle est uniquement qu'à tout new doit correspondre un delete. Il n'y a aucune obligation que celui qui réalise l'allocation doive faire la libération. Dieu merci, sinon on serait bien limité... Les problèmes de responsabilité ne se posent pas par hasard..

---

Il s'agit d'une règle simplifiée, mettant en œuvre le RAII qui ne limite rien du tout (!). Cela permet d'avoir une gestion simple des ressources.

En essayant d'éxécuter le 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

vector<double> sous_matrice(vector<double> & a,vector<int> & b, int m, int e,int l) { std::vector<double> cl; cl.reserve(m*e); int i,j; for(i=0;i<m;i++) for(j=0;j<e;j++) { cl[i*e+j]=a[i*l+b[j]]; } return(cl); } void main () { int n=5,m=3,i,j; vector<double> a,c; vector<int> b; a.reserve(m*n); b.reserve(m); c.reserve(m*m); a[0*n+0]=1; a[0*n+1]=1; a[0*n+2]=4; a[0*n+3]=5; a[0*n+4]=1; a[1*n+0]=2; a[1*n+1]=3; a[1*n+2]=6; a[1*n+3]=2; a[1*n+4]=4; a[2*n+0]=3; a[2*n+1]=2; a[2*n+2]=4; a[2*n+3]=0; a[2*n+4]=0; b[0]=1; b[1]=2; b[2]=3; for(i=0;i<m;i++) { for(j=0;j<n;j++) cout<<a[i*n+j]<<" "; cout<<endl; } c=sous_matrice(a,b,m,m,n); for(i=0;i<m;i++) { for(j=0;j<m;j++) cout<<c[i*m+j]<<" "; cout<<endl; } cin.get(); cin.ignore(); }

---

J'avait un Breakpoint: vector out of range c'est à dire il faudra insérer les élément de a et b et c par push_back() avant de les utiliser mais la complexité de cet opérateur et de o(n^2) si on veux insérer n élément, une autre solution et d'écrire

Code:

---

vector<double> cl(m*e)

---

et là le tableau sera initialiser à 0 dont plus d'opération alors qu'est ce que vous me coneiller de faire??

reserve permet de réserver de l'espace mais la taille est toujours à 0. Ce que tu veux faire ici est un resize.

Si tu connais la taille, donne la directement au constructeur. Le constructeur peut prendre la taille mais aussi la valeur par défaut.

Code:

---

1 2 3

vector<double> a(m * n, 0.); vector<double> c(m * m, 0.); vector<int> b(mn 0);

---

http://www.cplusplus.com/reference/v...vector/vector/
(Et oui par défaut, lorsqu'on donne la taillle à std::vector<T> il initialise avec T() qui vaut 0 pour les int et 0. pour les double.)

Tu gagnerais en lisibilité si tu encapsulais tes vectors linéarisés (comme a et c) dans une classe (comme vector2D...).

1-Oui je connais la taille de chaque vecteur et matrice, mais en terme de temps d'éxécution qui est le meilleur: initialiser les vecteur dès le départ par le contructeur ou bien utiliser l'opérateur push_back ou bien resize?

2-

Citation:

---

Ehonn
il manque donc un delete [] cl; cl = nullptr; // cl = 0; si avant C++11 (la régle est celui qui alloue est celui qui détruit)

---

alors celà veux dire que la fonction vas retourner un pointeur Null!!! en effet je l'ai essayé mais ily avait des erreurs de compilation; ce que j'ai fait est de librer après chaque appel de la fonction ptr=sous_matrice'a,b,l,e,m) le ptr mais la question qui se pose est ce qu'on a libérer le cl de meme pour a et b

Citation:

---

Envoyé par mathro

1-Oui je connais la taille de chaque vecteur et matrice, mais en terme de temps d'éxécution qui est le meilleur: initialiser les vecteur dès le départ par le contructeur ou bien utiliser l'opérateur push_back?

---

Le plus rapide est de donner la taille au constructeur (que ce soit en terme de lisibilité, maintenabilité, écriture et performance).
(push_back n'est pas un opérateur mais une fonction membre.)

Citation:

---

Envoyé par mathro

2-
alors celà veux dire que la fonction vas retourner un pointeur Null!!! en effet je l'ai essayé mais ily avait des erreurs de compilation; ce que j'ai fait est de librer après chaque appel de la fonction ptr=sous_matrice'a,b,l,e,m) le ptr mais la question qui se pose est ce qu'on a libérer le cl de meme pour a et b

---

J'ai jamais dit de faire le delete dans la fonction !
Ici la gestion de pointeurs par l'utilisateur est complètement inutile. Il faut utiliser std::vector pour les conteneurs 1D et la classe vector2D (qui est un std::vector linéarisé) pour les conteneur 2D. La taille est donné directement au constructeur. Et s'il la performance se dégrade à cause des copies dans le return : on change de compilateur, ou on utilise la move semantic de C++11, ou on passe l'objet par référence (soit avec la bonne taille soit on fait un resize).

Et oui je me suis trompé je m'excuse le push_back est une fonction membre et pas un opérateur.
Donc je vais donner la taille au contructeur et j'esseyerai de les passer par réference pour eviter la copie.
Je vous remercie infiniment Ehonn :ccool:

Voilà j'ai refait le deuxième projet le temps est améliorer de 6.214e+006 millisecondes à 1.971e+006 millisecondes mais reste toujours plus que la première version (projet 1) ou il ya que des allocation dynamique (109000 millisecondes):cry: :cry: :cry:

Tu as activé les optimisations par le compilateur ?
Si oui, il nous faudrait un exemple minimal qui reproduit la différence de performances pour t'aider.

J'ai pas activé les optimisations par le compilateur dans les deux cas c'est à dire pour les deux éxécutions. Je voudrais que le second aie le meme temps d'éxacution que le premier ou encore mieux avant d'activer les optimisations du compilateur

Ça n'a pas de sens de comparer des performances sans activer les optimisations.
Normalement utiliser std::vector et utiliser des tableaux dynamiques "à la C" donne les même performances. Cependant, l'auteur de la classe std::vector peut introduire des "trucs" en plus. Même sans ça, il y a des appels de fonctions avec l'utilisation de std::vector qu'il n'y a pas dans l'autre version.

Citation:

---

Envoyé par mathro

1-Oui je connais la taille de chaque vecteur et matrice, mais en terme de temps d'éxécution qui est le meilleur: initialiser les vecteur dès le départ par le contructeur ou bien utiliser l'opérateur push_back ou bien resize?

---

Le "plus rapide" sera surement le reserve et push_back, puisque le resize fait de l'initialisation à une valeur par défaut via l'opérateur T().

Maintenant, j'en pense qu'à ton niveau on n'en est pas à vouloir quelque chose qui tourne 0.0002ms plus vite mais tout simplement un script qui fonctionne.. :calim2:
Avant de vouloir courir, on apprend à marcher.

Citation:

---

Envoyé par Bousk

Le "plus rapide" sera surement le reserve et push_back, puisque le resize fait de l'initialisation à une valeur par défaut via l'opérateur T().

---

J'ai trouvé que push_back est de complexité o(n^2) si on veux insérer n élement, c'est pour ça je l'ai pas utilisé.

Enfin merci beaucoup Ehonn il faudra activer les optimisations :ccool:

Citation:

---

Envoyé par mathro

J'ai trouvé que push_back est de complexité o(n^2) si on veux insérer n élement, c'est pour ça je l'ai pas utilisé.

---

C'est faux. Insérer n éléments est en O(n).

Bonjour,

Vis à vis des grosses différences de performance, et vu que tu sembles utiliser Visual Studio 2010, j'ai peut-être une idée du problème.

Dans la configuration par défaut du mode Debug, il y a l'option "Basic Runtime Check" (dans les options de compilation C/C++ => Code Generation) qui semble ralentir énormément les objets de type class quand il n'est pas mis sur Default.

J'ai remarqué ça quand j'ai fait un simple wrapper autour de l'API random du système (méthode Rand() qui appel la fonction rand() du système). En mode Release, les temps étaient sensiblement semblable, mais en Debug, ils étaient juste beaucoup trop éloignés.

Sans l'option de compilation modifiée : API C : 16s, wrapper class : 25s
Avec l'option de compilation modifiée : API C : 17s, wrapper class : 19s

Et sinon vu qu'on travaille en taille fixe, on peut aller chercher std::array dans C++11 ou Boost.

Citation:

---

Envoyé par ketan

Dans la configuration par défaut du mode Debug, il y a l'option "Basic Runtime Check" (dans les options de compilation C/C++ => Code Generation) qui semble ralentir énormément les objets de type class quand il n'est pas mis sur Default.

---

J'ai éxécuter une partie du code la ou le problème ce pose, sans changer cette option de compilation j'ai eu les résultats suivant
Allocation dynamique: 14 s; class std::vector 97 s
En changeant cette option
Allocation dynamique: 14 s; class std::vector 52 s
en activant de plus les optimisation (/O2; /Ot)
Allocation dynamique: 13 s; class std::vector 30 s

En faisant l'éxécution du programme en entier avec des données de taille moyenne (n=30) avec activation des optimisations (/O2, /Ot) mettre l'option 'Basic Runtime Checks' à 'Default' et l'option 'Debug Information format' à 'C7 compatible (/Z7)' car /ZI n'est pas compatible avec /O2, j'ai eu les résultats suivants:

Allocation dynamique
Debug:76s ; Release:33s
std::Vector
Debug:175s ; Release:32s

Donc voilà, il faudra exécuter en mode Release :ccool: ; reste à voir C++11 :roll:

Citation:

---

Envoyé par Bousk

Le "plus rapide" sera surement le reserve et push_back, puisque le resize fait de l'initialisation à une valeur par défaut via l'opérateur T().

Maintenant, j'en pense qu'à ton niveau on n'en est pas à vouloir quelque chose qui tourne 0.0002ms plus vite mais tout simplement un script qui fonctionne.. :calim2:
Avant de vouloir courir, on apprend à marcher.

---

+1000

Ceci aussi aide un peu à retirer des casseroles inutiles sous VS:
_SECURE_SCL=0

J'use et abuse de std::vector<> dans mes prg.
Je n'ai jamais fait de resize() et n'ai jamais initialisé un vector à une taille donnée, la plupart du temps c'est inutile et contreproductif.
Par contre les méthodes reserve() et capacity() sont utiles et importantes.

Voici un exemple de bon usage:

Code:

---

1 2 3 4

std::vector<int> v; v.reserve(1000); for (int i=0; i<1000; ++i) v.push_back(i);

---

Voici un exemple catastrophique :aie:

Code:

---

1 2 3 4 5 6

std::vector<int> v; for (int i=0; i<1000; ++i) { v.reserve(v.capacity()+1); v.push_back(i); }

---

Citation:

---

Envoyé par camboui

Je n'ai jamais fait de resize() et n'ai jamais initialisé un vector à une taille donnée, la plupart du temps c'est inutile et contreproductif.

---

Dans le traitement d'image, tu connais la taille de l'image avant de déclarer ton vector donc tu peux l'initialiser directement à la bonne taille. Tu ne peux pas utiliser std::array (ou un tableau à la C) car cette taille n'est connu qu'à l'exécution (et que tu ne peux pas t'assurer que ton image tienne dans la pile). Utiliser reserve ici serait inutile et contre productif.

Pour ton exemple, je pense que ceci est plus rapide si l'initialisation est plus rapide que le surcoût dû au push_back (même sans réallocation) (à tester) (mais c'est pas toujours possible j'en conviens).

Code:

---

1 2 3 4 5

std::vector<int> v(1000); for (std::size_t i = 0; i < v.size(); ++i) { v[i] = i; }

---

Citation:

---

Envoyé par Ehonn

Dans le traitement d'image, tu connais la taille de l'image avant de déclarer ton vector donc tu peux l'initialiser directement à la bonne taille. Tu ne peux pas utiliser std::array (ou un tableau à la C) car cette taille n'est connu qu'à l'exécution (et que tu ne peux pas t'assurer que ton image tienne dans la pile). Utiliser reserve ici serait inutile et contre productif.

---

Le traitement d'image ne fait pas exception.
As-tu une quelconque utilité à initialiser les élément de ton vector à une valeur donnée ? Je n'en ai jamais eu besoin en faisait du traitement d'image.
Le vector sert à stocker les pixels, on sait combien on veut en stocker, initialiser notre stockage par un pixel/une couleur par défaut à chaque emplacement/pixel ne sert à rien. On réserve la taille nécessaire, puis on lit/écrit/stocke chacun des pixels.

Citation:

---

Envoyé par Ehonn

Pour ton exemple, je pense que ceci est plus rapide si l'initialisation est plus rapide que le surcoût dû au push_back (même sans réallocation) (à tester) (mais c'est pas toujours possible j'en conviens).

---

Code:

---

1 2 3 4 5

std::vector<int> v(1000); for (std::size_t i = 0; i < v.size(); ++i) { v[i] = i; }

---

Etant donné l'appel au constructeur par défaut *1000 avant, non.
Le push_back ne coûte rien tant qu'il ne doit pas faire une réallocation.
L'opérateur[] utilise le constructeur par copie, tout comme le push_back.

Je trouve qu'il est plus simple (et plus court) d'utiliser la size du vector.

push_back fait un if que operator[] ne fait pas, l'operator[] est donc potentiellement plus rapide.

Citation:

---

Envoyé par Bousk

Le traitement d'image ne fait pas exception.
As-tu une quelconque utilité à initialiser les élément de ton vector à une valeur donnée ? Je n'en ai jamais eu besoin en faisait du traitement d'image.
Le vector sert à stocker les pixels, on sait combien on veut en stocker, initialiser notre stockage par un pixel/une couleur par défaut à chaque emplacement/pixel ne sert à rien. On réserve la taille nécessaire, puis on lit/écrit/stocke chacun des pixels.

---

Il me semble qu'on est assez souvent amené à devoir utiliser des bibliothèques C, auquel cas on est obligé de faire un resize pour à la fois allouer la mémoire et dire au std::vector qu'il contient quelque chose. Même si l'initialisation des valeurs est effectivement inutile dans ce cas.

Salut,

Citation:

---

Envoyé par Kalith

Il me semble qu'on est assez souvent amené à devoir utiliser des bibliothèques C, auquel cas on est obligé de faire un resize pour à la fois allouer la mémoire et dire au std::vector qu'il contient quelque chose. Même si l'initialisation des valeurs est effectivement inutile dans ce cas.

---

Ben, j'ai presque envie de dire que, dans ce cas là, on disposer d'un constructeur particulièrement sympa...

Au sortir d'une bibliothèque C, on aura sans doute soit un char * soit un void * (soit même un UnType * qui correspond à la structure C en question), mais on aura, aussi, une indication du nombre d'éléments que l'on doit s'attendre à y trouver.

Une fois la conversion (si nécessaire) effectuée du char * ou en void * en un UnType*, tu devrait pouvoir utiliser le constructeur prenant les deux itérateurs, sous la forme de

Code:

---

std::vector<UnType> tab(ptr, ptr+size);

---

Il me sembleque ce constructeur commence par calculer la taille requise (std::distance) et par faire un reserve avant de faire l'équivalent d'un grand memcpy global ;)

Citation:

---

Envoyé par mathro

Citation:

---

Puisque tu fais un retour par copie, il pourrait également être plus intéressant de passer le vector en paramètre out de la méthode à la place.

---

Je comprend pas exactement ce que vous voulez dire

---

je pense qu'en parlant de retour par copie il parle de ce sujet
http://stackoverflow.com/questions/1...nt-copy-values
http://en.wikipedia.org/wiki/Return_value_optimization

cela peut couter cher un retour par copie ou pas…

Citation:

---

Envoyé par koala01

Ben, j'ai presque envie de dire que, dans ce cas là, on disposer d'un constructeur particulièrement sympa...

---

Oui bien sûr, et il serait bête de s'en priver ;) Mais j'ai déjà vu des cas (par exemple avec libpng) où la bibliothèque ne gère pas la mémoire elle même, et attend qu'on lui donne un pointeur vers une zone mémoire valide où elle pourra ranger les pixels.

Citation:

---

Envoyé par Kalith

Oui bien sûr, et il serait bête de s'en priver ;) Mais j'ai déjà vu des cas (par exemple avec libpng) où la bibliothèque ne gère pas la mémoire elle même, et attend qu'on lui donne un pointeur vers une zone mémoire valide où elle pourra ranger les pixels.

---

Perso dans ces cas-là, je préfère utiliser un simple C-Array, et si j'ai vraiment besoin d'un vector par la suite, je crée un vector avec après :)

Citation:

---

Envoyé par jabbounet

je pense qu'en parlant de retour par copie il parle de ce sujet
http://stackoverflow.com/questions/1...nt-copy-values
http://en.wikipedia.org/wiki/Return_value_optimization

cela peut couter cher un retour par copie ou pas…

---

Cela peut aussi coûter moins cher :
Want speed ? Pass by value