Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-08-26 07:49:19


Andreas Huber wrote:
> [snip]
>> So far my experience indicates that people only bother with
>> allocators when std::allocator is inadequate, i.e. slow.
>
> ... or non-deterministic. Using such an allocator in a hard real-time
> system is simply not an option.
> AFAIK, a deterministic allocator must inevitably have a separate heap
> for each possible object size. The difficult part is reserving enough
> slots in each heap at startup, before deterministic reaction is necessary.
I don't
> see how a system could do this automatically when memory is scarce.

The usual approach is to borrow an entry from the 2*N heap and split it in
two when the N heap is empty. Most contemporary allocators do maintain
per-size buckets for small allocations even for non-realtime systems since
this improves performance and reduces fragmentation dramatically.

Even if the system allocator does not work for you, why would you want to
only replace function<>'s allocator but leave all other allocations
non-deterministic? And how would the ability help you if you want to use a
third party library that has signatures of the form

void f(function<void()> const & g);

?

Remember that one of the main uses of function<> is to turn the template

template<class G> void f(G g);

into a non-template like the above, and non-templates can't have an
allocator template parameter.

I won't even go into details like whether std::allocator's interface is
suited for the task or whether the function<>'s specification as it
currently stands gives you any guarantees for deterministic behavior.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk