On Fri, Jun 17, 2011 at 8:05 AM, Daniel James
On 17 June 2011 12:37, Gokulakannan Somasundaram
wrote: Hmmm.. may be i am ignorant here. But here we are referring to classes which contain containers like string and vector and deque.
Then you're restricting future changes to the implementation by saying that memory can only managed using containers. You've also still got the problems I mentioned with separate compilation and increased complexity. For example, boost::filesystem::path is not a template and is largely compiled separately. If allocator support was required, that wouldn't be possible.
The more general point is that adding any extra feature to a library increases its complexity and with each new feature this accumulates. So no extra feature is ever just a simple change.
Custom allocation doesn't always need to be done via template arguments. If, for example, boost::filesystem only needs to allocate a string at some point, maybe a specific "string supplier" could be passed in. Just something to customize allocation. Might not work in all cases - I don't think we can enforce custom allocation for every boost library - but we can encourage it in whatever way works for the problem at hand. Tony