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