Why juce does not include a memory pool? Because it is unnecessary?
“Memory pool” could mean a thousand different things… Can you be more precise?
Just a guess but I think he wants a custom allocator that outperforms stdlib. This is completely unnecessary for anything but high performance concurrent system.
I agree with the idea that a custom allocator is VERY helpful for such a system, but it would be completely inappropriate to include one in Juce. First of all, there are plenty of commercial and non-commercial replacements for the standard allocators, which are designed for concurrent usage. They are mostly platform/IDE specific and require some linker re-jiggering to get their substitutes for new/delete/malloc/free in place.
But more importantly, a custom allocator would be optimized based on the specifics of the application in question (or else the standard allocator would suffice). How is Juce supposed to provide a general purpose allocator specific to your app’s needs?
If you want a custom allocator, you should write it yourself, and take advantage of your application’s unique data access patterns to achieve a performance increase. Ideally, this would be one of the last steps before the application is completed, and only after determining that memory allocation is indeed a bottleneck.
Memory pool … just like boost:: memory pool and SGI STL.
The problem comes from some time ago I saw a book on multi-threaded programming, which is referred to as “thread safe”, I used the SGI STL’s memory pool, it’s cool, but not thread-safe, so I was thinking, since juce provides multi-threaded programming solutions, why not include a thread-safe memory management? so I just want to ask why …
What’s wrong with stdlib? It’s thread-safe…