Ion Gaztañaga wrote:
If ::operator new isn't terribly broken (if it is, use dlmalloc), memory waste will aready be minimal and allocation would already be fast for small objects. Custom per-component allocators are rarely worth the trouble, and should never be the default.
In some experiments, I see that for example, in windows, the default allocator uses pools for small objects, but this is not true in all systems. For example, in many embedded operating systems (for example, QNX, eCos, Nucleus... and correct me if someone knows these OS better than me), there is no optimized new. In these systems, more than speed problems, you can have fragmentation problems.
[...]
Maybe a bit of paranoia, but not all "new" implementations are optimized and pooled for small allocations.
They aren't. My point is that the solution is to globally replace ::operator new or malloc with one that is, not make every component deal with the possibility in its own (incompatible and possibly inferior) way. BTW, Windows's allocator is far from being one of the best. Good general-purpose allocators match quick_allocator in the ST case and run circles around it in the MT case. The main reason that it was included is contrived "shared_ptr vs ..." benchmarks. For real applications, even dlmalloc is better. :-)
I agree with you that this shouldn't be default, though. "new" should be default, but I suggest a mechanism to override this mechanism with user defined allocations. I would love to see that mechanism in shared_ptr for the counter, because for the object itself you can use a custom deleter. But this is another history.
The CVS version of shared_ptr supports custom allocators.