Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-12-18 06:07:10

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at