Douglas Gregor wrote:
> The allocator design focused on the benefits one could get from
> specialized allocators for containers, e.g., data structures that may
> allocate large chunks of memory that are expected to be used
> together. They don't really give us much for components like
> shared_ptr that allocate one thing (and
> note that shared_ptr does not allocate the pointer it stores,
> although it does allocate a reference count). boost::function
> supports an allocator argument, but the C++ committee is considering
> removing this allocator from the library TR version of function<> for
> precisely this reason.

If function no longer has the allocator argument, how should we then use
function in a hard real-time environment? Does the committee assume that
such systems have deterministic allocators or that users replace global
new/delete anyway?

Thanks & Regards,

Andreas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to