Re: [Boost-users] Request for an addition in Boost Coding standard

Subject: Re: [Boost-users] Request for an addition in Boost Coding standard
From: Ovanes Markarian (om_boost_at_[hidden])
Date: 2011-06-19 08:32:51

On Sun, Jun 19, 2011 at 4:10 AM, Gottlob Frege <gottlobfrege_at_[hidden]>wrote:

> On Fri, Jun 17, 2011 at 8:05 AM, Daniel James <dnljms_at_[hidden]> wrote:
> > On 17 June 2011 12:37, Gokulakannan Somasundaram <gokul007_at_[hidden]>
> 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