Discussion :

[mintho carmo]

@Kaamui: le but premier d'un pool d'objets est d’éviter les allocations/libérations (très coûteux) durant la boucle de jeu. On pré-alloue un tableau d'objets et dans le boucle on fait simplement passer un objet d'un état "invalide" a "valide".

[LittleWhite]

(HS : n'oublie pas de mettre noexcept dans le constructeur par mouvement de T - si possible - pour conserver la strong garantie exception de emplace_back)

Ça veut dire que pour toutes les classes que j'utilise dans la Pool, je dois réimplémenter le constructeur par mouvement ?
De plus, pouvez vous me donner des détails sur le noexcept (surement pour indiquer que ma fonction ne lance pas d'exception), mais quelle est la strong garantie de emplace_back ? Genre emplace_back donne la garantie de ne pas lancer une exception ?

C'est moi, où leur exemple ne réimplémente pas le constructeur par mouvement avec le noexcept : http://en.cppreference.com/w/cpp/con...r/emplace_back ?

(HS2 : et tu devrais prendre l'habitude d'utiliser using au lieu de typedef)

Je le fais ce soir. Merci pour la remarque.

Une idée: un objet qui référence un int et l'incrémente à chaque copie. Vérifier ensuite que la valeur attendue est la même que le nombre de copie supposé.

L'idée n'est pas mauvaise, si j'avais une totale maitrise des nouveaux principes de mouvement. Maintenant, cela demande de réimplémenter tous les constructeur (et opérateur de copie) possible, pour tracker ce qui se passe derrière les coulisses. C'est une chose que je vais peut être tenter, car c'est un bon exercice.
La vérité, c'est plus : je cherchais à comprendre valgrind/massif un peu mieux, car après mes expérimentations, j'avais pas mal pataugé . Je voulais aussi éviter de faire du code pour ça.

@Bousk : je vois. C'est une approche totalement valable .

@Kaamui : le code est certainement compliqué. Deux raisons à cela : je m'entraine au C++11 et j'ai un peu renoncé à faire de la modélisation réflexion en amont, pour pouvoir coder, car en ce moment, je veux coder, quitte à faire plein de refactoring par la suite (et c'est ce que j'ai fait plusieurs fois déjà). Je teste la SFML aussi, mais là dessus, ça se voit moins. Donc, oui, je vous l'accorde, mon code, je le qualiferai de pourri. Surtout lorsque l'on voit ce que fait ce gars.
Maintenant, pour le coté Pool. mintho carmo a déjà répondu à la question. Les allocations sont ultra lentes (en théorie, je dis bien en théorie car je ne l'ai jamais senti moi même). Cela est gênant dans une boucle de jeu qui doit tourner au plus sur 16ms. Surtout en utilisant std::vector, les pics de ralentissement peuvent ne pas être contrôlés (le push_back() qui alloue de la mémoire quand il "veut" dépendant de l'implémentation). Bon, sur PC, le problème est réduit, mais sur console cela pourrait être une vraie plaie. Et comme mon code est là pour m'amuser, autant faire une Pool, cela me permet d'expérimenter plus avec le emplace_back(), avec le using , avec tout....
Mais, il y a un autre aspect, c'est que j'ai mis mes particules dans la Pool. À chaque explosion d’ennemies vous avez 100 particules qui pop pour 1 secondes et qui disparaissent. En mémoire dynamique, ça serait la mort à chaque explosion, donc la Pool. Les ennemies sont créer au fur et à mesure, ainsi que les particules. C'est pour ça que l'on ne peux pas dire juste : toutes les instances on une durée de vie fixe. Ou alors, j'ai voulu faire un pong .

Sur console, on aime bien avoir contrôle sur tout, notamment toutes les allocations mémoire, car on est limité. Avoir une Pool, c'est dire : "J'ai un bloc pour 1000 particules, ça prend (exemple théorique) 16ko". Je ne peux pas en avoir une de plus, donc, j'ai le reste de la mémoire pour le reste de mon jeu (les textures, qui sont bien plus importantes, par exemple). Mais l'idée est aussi d'avoir un suivi bien plus précis. On peut même faire son propre alloueur de mémoire... mais ça, je n'aime pas .

On remarquera que ma pool diminue la fragmentation. J'ai un bloc d'une taille N, je peux boucler linéairement dessus, car je l'ai alloué d'un coup au début.