c'est juste à titre informatif, je sais pas si y en a qui suive comp.lang.c++.moderated , le fait est que cette après-midi je faisais des petites recherches sur Google, j'épeluche régulièrement les thread par posteur et je suis tombé sur celui là: un petit thread anodin, et une réponse intelligente de Andrew Koenig
 
http://groups.google.com/groups?hl [...] et.att.net
 
en bref, quand on agrandit un vecteur (ou assimilé) en fonction de l'allocateur, il est souvent avantageux d'agrandir par un facteur ~1,5 plutot que par 2
 
un astuce en or

ça m'apprendra à poster des sujets, je suis mauvais qu'à répondre

interressant, mais personnellement comme je cherche le max de perfs aux dépends de la STLisité, j'ai fais mes propres conteneurs (à la vector) qui évitent de repasser par la méthode, allocation du nouveau => copie ancien => nouveau => supression ancien (dans le cas du vector, mais bien sûr y'a des restrictions à prendre en compte dans les types d'objets).
 
sinon

le problème avec ton aproche, c'est que tu violes la POO puisque la sémantique est clair : recopie -> constructeur de copie / operator=
 
la STL n'a jamais été aux dépends des performances ... au lieu de réinventer, t'es sur de pas plutot avoir un simple problème d'allocateur ?

Précision : ça ne concerne que les first-fit (les trucs à la C).
 
Mais ça explique pourquoi j'ai vu du 1.5 se trimballer plusieurs fois.

 
c'est possible pour l'allocateur, par contre pour la violation de la POO c'est potiellement pas faux ta remarque.
 
mais ce que je vois avec le vector c'est que tu as un vector de 256 mo, et qu'il doit redimmentionner tu te retrouves une utilisation crête de plus d'au moins 512mo ( l'ancien + le nouveau plus grand ). obligatoirement si tu passes par les étates (allocation du nouveau => copie ancien -> nouveau => supression ancien)
 
bon j'ai juste fais quelques essais perso, mais j'avais trouvés des articles chez ibm sur des critiques de la STL (en perfs, surpic mémoire etc...).
 
maintenant c'est fortement possible que j'ai réinventé ce qui existe déjà...

même dans d'autres algorithme, ça doit quand même améliorer la probabilité de recycler, puisque dans certains cas best et first arrive au même résultat, je pense que ce facteur est avant tout crucial pour les gros morceaux de mémoire

Je pensais surtout à ceux qui font pas de fitting ...
 
Je pense que ça joue dans le cadre de collection qui changent beaucoup de taille, si tu pars d'une collection de 1 élément et que tu vas à 15000, l'allocateur risque de souffrir, plus que la copie.

(1+srqt(5))/2, c'est le nombre d'or
 
PS : il a oublié les parenthèses ?

en fait c'est la solution de x^2 - x - 1 = 0
qui a deux racines (1 + sqrt(5)) / 2
et (1-sqrt(5))/2
 
seule la premiere est interessante
puisque la deuxieme est negative. (et un facteur de croissance est generalement positif..)
 
LeGreg

oui en fin bon, avec un polynôme on voit pas grand chose. par contre
 
x² = x + 1
 
la on comprend tout de suite

Intéressant le newsgroup C++ (même si je ne suis pas loin de penser que le C++ est un langage qui n'a plus bcp d'intérêt).
 
Il semble être fréquenté par quantité d'experts.

Mais c'est le cas.

Oui oui, je l'ai bien vu. Scott Meyers par exemple.

Bof, y a bien plus gros comme pointure. Peutêtre pas des best-sellers, certes