Dans le cas général (oui on va parler de temps réel dur, d'embarqué, etc), le préfère définitivement laisser un gc s'occuper de ça et si je rencontre un problème le paramétrer ou passer le bout de code qui pose problème « Off the heap », plutôt que de faire l'inverse.
Dans le cas général, tu laisses la RAII et malloc() gérer ça. Dans le cas où tu utilises un home-made Allocator pour faire des (millions) d'allocations en chaine de petit objets, c'est déja un cas qui tuerait 90% des GC.
Pour faire ce genre de choses il te faut une vision assez précise des cas d'utilisation. Pour cet exemple, il faut savoir quelle va être la quantité de mémoire utilisée (ou faire une estimation)
Généralement en C/C++, tout bon allocator est une chaine d'allocator. Tu fais une estimation pour une première pool X, si elle se remplit tu alloues une deuxième pool Y, si elle se remplit, tu te rabas sur malloc() ou similaire.
Il y a un trés bon talk à la dernière CPPcon sur le sujet si certaines personnes sont interessées.
[^] # Re: Destructeurs
Posté par Firwen (site web personnel) . En réponse à la dépêche Crystal, un langage proche de Ruby, en version 0.16. Évalué à 2.
Dans le cas général, tu laisses la RAII et malloc() gérer ça. Dans le cas où tu utilises un home-made Allocator pour faire des (millions) d'allocations en chaine de petit objets, c'est déja un cas qui tuerait 90% des GC.
Généralement en C/C++, tout bon allocator est une chaine d'allocator. Tu fais une estimation pour une première pool X, si elle se remplit tu alloues une deuxième pool Y, si elle se remplit, tu te rabas sur malloc() ou similaire.
Il y a un trés bon talk à la dernière CPPcon sur le sujet si certaines personnes sont interessées.