Memory, Allocator<T> & __USE_MALLOC & alternatives

[Tony Bryant]

> Also, I would like to ask you to consider another option as a
> direction for your work.  It was common in my experience with C
> embedded systems that the application wants to tightly control
> allocation of memory.  Thus, I wonder if instead of a global policy to
> change the default allocator, if you couldn't override the allocator
> for STL objects and containers when declaring them.  This way the
> matter is controlled in the application source code (make a point of
> indirection through a single typedef to make late tuning easier)
> instead of yet another #ifdef controlled option that causes
> recompilation of the entire library...  Thus, I would see your work as
> providing an optional allocator at the definition point of all STL
> objects instead of as a global option.

The trouble with this approach is the some STL containers don't allow 
allocators to be defined (e.g. std::string, std::priority_queue, and I 
imagine the iostream stuff ).

Not exactly the tidiest source code either.

The lack of an allocator specifier for std::string is the killer I think. I 
don't suppose there's an ISO standard "std::stringwithallocator<ALLOC>" 
template?