On Sun, Jun 19, 2011 at 4:10 AM, Gottlob Frege <gottlobfrege@gmail.com> wrote:

On Fri, Jun 17, 2011 at 8:05 AM, Daniel James <dnljms@gmail.com> wrote:
> On 17 June 2011 12:37, Gokulakannan Somasundaram <gokul007@gmail.com> 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