Peter Dimov wrote: > 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. [snip]
Which brings back non-determinism, as the 2*N heap could be full also and thus be borrowing from 4*N already. You can of course guarantee an upper limit for an allocation, as some heap must have a slot available. However, for some systems this upper limit is already too slow, so someone inevitably has to configure heap sizes *before* startup. > 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? Because function objects absolutely have to be allocated during the phase when a system has to react deterministically. Other objects might be allocated before this phase. I guess your hinting at replacing global new/delete, which almost always works but only almost as Eugene explained. > 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); Yep, no luck here. [snip] > 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. I didn't say std::allocator is perfect, but it's standard ;-). function's spec indeed doesn't guarantee determinism, but I couldn't think of a reasonable implementation that isn't deterministic. Regards, Andreas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost