Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.
Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?
Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.
Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?
[^] # Re: works for me
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
Gni ? L'implémentation de std::vector n'est pas obligée de faire une préallocation si on ne donne pas de capacité initiale. Si le constructeur par défaut le fait quand même, c'est un problème de qualité d'implémentation de std::vector.
Si dans ton cas particulier le vector contient généralement 10 elements, rien ne t'empeche de faire un reserve(10) avant la premiere insertion, que le vecteur soit alloué dynamiquement ou non.
Si tu dois de toute facon avoir du code avant la 1ere insertion, pourquoi alors te taper ces 12 bytes additionels tout le temps ?
Un simple pool de char[sizeof bob] obtenues via l'allocateur est suffisant.
Et il a quelle taille ton pool ? Tu alloues un gros bloc bien enorme qui mange la RAM et qui a l'effet oppose(je te rappelles que l'objectif est minimiser l'utilisation memoire hein) ou tu alloues plusieurs blocs a la demande auquel cas il te faut gerer les allocations/deallocations des blocs complets avec tracking, etc... ?