On Sun, Jun 21, 2020 at 10:32 AM Vinnie Falco via SG16
<sg16_at_[hidden]> wrote:
>
> On Sun, Jun 21, 2020 at 7:16 AM JeanHeyd Meneide via Boost
> <boost_at_[hidden]> wrote:
> > ...neither have allocators built in so I
> > can't really customize how this works without hijacking global new and
> > delete, but Zach has made clear his distaste for the allocator world
> > ...
> > - Allocators are shit!
> > ...
> > "who died and made you King of my string...memory allocation?
> > ...
>
> The inability to control how and where memory is allocated is a
> significant obstacle to using ANY container in a concurrent network
> server. In every case, the first step of improving the performance of
> such a program is to reduce the number of calls to allocate memory.
> Often, simply reducing memory allocations is sufficient to give the
> program desired performance.
>
> A typical asynchronous network program follows a predictable cycle of
> operations in a thread:
>
> 1. Data is received from the remote peer
> 2. Memory is allocated to perform the operation
> 3. The operation is performed
> 4. Allocated memory is freed
> 5. Control of the thread is returned to the I/O subsystem
>
> It is in steps 2 and 4 where a custom allocator is used to optimize
> the I/O cycle. The techniques are simple:
>
> 1. Reuse a previously allocated block of memory
> 2. Utilize the stack for storage (preferred when the storage
> requirements for the operation are bounded)
>
> Without the ability to control the allocator, these optimizations are
> not possible with the containers in Boost.Text.
>
> I have not looked deeply enough into Boost.Text, nor am I
> knowledgeable enough about Unicode to write a competent review.
> However, were I to write such a review I would REJECT the library for
> the sole reason that it does not support allocators and thus cannot be
> used optimally in a network program.
>
> If the author decides to add allocator support, I suggest rather than
> using an Allocator template parameter, to instead use
> `boost::container::memory_resource&` as a constructor parameter (or
> `std::pmr::memory_resource&` if available). This allows the container
> to be implemented as an ordinary class instead of a class template.

Wait. Is it your opinion that nothing that allocates memory and does
not have an allocator should be added to Boost? That's... weird, if
so. Many Boost libraries allocate memory and do not support
allocators.

Zach