Subject: Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-10-04 15:02:52
On Wed, Oct 4, 2017 at 7:51 AM, paul <pfultz2_at_[hidden]> wrote:
> Ideally, the constructor to `buffer` or `const_buffer` should take any class
> that has a `.data()` and `.size()` member. This way `value_type` can fulfill
> the requirement of `ConvertibleToBuffer` without needing the dependency on a
> concrete type.
That is quite a good idea! But that would require a change to the
Networking-TS which means writing a paper. And it would have to be
changed in Asio as well, since we're modifying the meaning of a
> Another option, is just moving these concrete buffer classes from Asio to your
> new library...
Yes, that is the approach that I am taking with Boost.Buffers
>...and then Boost.Asio will depend on Boost.Buffers.
Of course that would be great, but I can't presume that the author
would be open to making that dependency. We also have to be mindful
that stand-alone Asio is the upstream library - Boost.Asio is
generated from stand-alone Asio via script. In order to make
Boost.Asio depend on Boost.Buffers some accomodation would need to be
However, making Boost.Asio depend on Boost.Buffers is not strictly
necessary, I have a work-around that lets the user decide where to get
the header files from:
I plan on moving beast's dynamic buffer implementations and buffer
adapters into Boost.Buffers as well, I will describe this plan in a
new post shortly.