Boost logo

Boost :

Subject: Re: [boost] ASIO into the standard (was: Re: C++ committee meeting report)
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-07-04 07:07:35


On Fri, Jul 4, 2014 at 12:46 PM, Neil Groves <neilgroves_at_[hidden]> wrote:

> On 4 Jul 2014, at 10:47, Jonathan Wakely <jwakely.boost_at_[hidden]> wrote:
>
> > On 1 July 2014 22:45, Felipe Magno de Almeida wrote:
> >>
> >> I would hope Allocators would be added to ASIO in the standard. It
> >> is difficult to limit memory usage without Allocators in embedded
> >> systems.
> >
> > I hate this recurring theme of "let's take something that works well
> > today and then fsck it up by insisting it has allocator support”
> >
>
> Since I am far less familiar with these issues than you are the solution
> to avoiding detriment to designs by having allocator support is not obvious
> to me. What should we do instead of adding allocator support? Should we be
> improving the standard allocator like the implementations in
> Boost.Container, or are you suggesting that any standardisation of the
> allocator Concept would lead to a deterioration of the design? My own view
> is that the standard allocator is clearly suboptimal even for standard
> containers. This is evident from the performance improvements obtained in
> Boost.Container. I have noticed though that the improved allocators do not
> provide superior performance on Linux systems over the standard
> implementations. I’m very interested in your proposed solutions as I
> suspect there is much to learn from your experience working on the standard
> library implementations.
>

As a quick side-note, there have been recent C++ proposals for improving
the situation, like N3525[1]. (I don't know if Boost.Container already have
similar features.)

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3525.pdf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk