Re: [boost] ASIO into the standard (was: Re: C++ committee meeting report)

Subject: Re: [boost] ASIO into the standard (was: Re: C++ committee meeting report)
From: Jonathan Wakely (jwakely.boost_at_[hidden])
Date: 2014-07-04 10:33:32

On 4 July 2014 11:46, Neil Groves 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,

I'm not familiar with those implementations, so I can't comment on
them. Does Boost.Container do more than the C++11 allocator
requirements (i.e. support stateful and scoped allocators, via
allocator_traits)?

> or are you suggesting that any standardisation of the allocator Concept would lead to a deterioration of the design?

Possibly, yes.

Every time a new class gets accepted for standardisation it then gets
allocator support slapped on, sometimes despite the fact it's never
been implemented and in at least one case is impossible to implement
(as happened when boost:any became std::experimental::any).

If allocator support is important to asio why isn't it there already?
Has it been suggested? Has it been implemented? Has it been shown to
be useful?

The job of the standards committee should not be to "improve" things
that work well already (which is not to say that some things can't be
adapted to suit additional use cases, such as better control of memory
allocation if that really is needed).

> 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.

My opinion is that the refrain "it needs allocator support" wastes
vast quantities of WG21 committee time and effort for arguably  little
benefit.