On Sun, Jun 19, 2011 at 4:10 AM, Gottlob Frege
On Fri, Jun 17, 2011 at 8:05 AM, Daniel James
wrote: 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
On the other hand C++ is so flexible, that you just can specialize the std::allocator for the character class you need (which is e.g. used by boost::path), and all the characters will be allocated by your own allocator specialization. Additionally, there might be some pitfalls, since this approach is more general and involves all character sequences to be allocated with your allocator. If such string objects are passed outside of .dll or .so libraries it might introduce problems, since these string objects must be destroyed accordingly with new allocator and not the default one. But anyway it should be possible even now ;) With Kind Regards, Ovanes