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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost