Re: [boost] [beast] A Networking-TS version of Boost.Asio and Boost.Beast is here!
On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
My preview of Boost.Asio version 1.66.0 is here:
Upon re-reading the message I realize that it might be confusing, so to clarify - this is NOT an "official" version of Boost.Asio it is just an experimental branch of what Boost.Asio might look like soon, for anyone who wants to try out the latest stand-alone Asio features in the Boost.Asio context. Thanks
On Tue, 2017-10-03 at 10:42 -0700, Vinnie Falco via Boost wrote:
On Tue, Oct 3, 2017 at 9:40 AM, Vinnie Falco <vinnie.falco@gmail.com> wrote:
My preview of Boost.Asio version 1.66.0 is here:
Upon re-reading the message I realize that it might be confusing, so to clarify - this is NOT an "official" version of Boost.Asio it is just an experimental branch of what Boost.Asio might look like soon, for anyone who wants to try out the latest stand-alone Asio features in the Boost.Asio context.
How do the Buffer concepts change to depend on networking? The way the buffers are defined now, there is no dependency on Boost.Asio. .
On Tue, Oct 3, 2017 at 2:23 PM, paul <pfultz2@yahoo.com> wrote:
How do the Buffer concepts change to depend on networking? The way the buffers are defined now, there is no dependency on Boost.Asio.
Are you suggesting that the Net-TS buffer concepts do not depend on Boost.Asio? That's not entirely correct. Net-TS buffer sequence iterator value types must be convertible to `std::experimental::net::const_buffer` or `std::experimental::net::mutable_buffer`. In the Net-TS compatible version of Asio these types are `boost::asio::const_buffer` and `boost::asio::mutable_buffer`. There is simply no way to avoid the dependency on these concrete types in Asio. In my other post I am proposing a library Boost.Buffers to work around this problem, so that people (like me) can write libraries which use only Asio buffer concepts, without a dependency on all of Asio (and everything that Asio depends on, recursively). Thanks
On Wed, 2017-10-04 at 06:39 -0700, Vinnie Falco via Boost wrote:
On Tue, Oct 3, 2017 at 2:23 PM, paul <pfultz2@yahoo.com> wrote:
How do the Buffer concepts change to depend on networking? The way the buffers are defined now, there is no dependency on Boost.Asio.
Are you suggesting that the Net-TS buffer concepts do not depend on Boost.Asio? That's not entirely correct.
Net-TS buffer sequence iterator value types must be convertible to `std::experimental::net::const_buffer` or `std::experimental::net::mutable_buffer`. In the Net-TS compatible version of Asio these types are `boost::asio::const_buffer` and `boost::asio::mutable_buffer`.
I see, that requirement comes from here: http://www.boost.org/doc/libs/1_65_1/ doc/html/boost_asio/reference/ConvertibleToConstBuffer.html
There is simply no way to avoid the dependency on these concrete types in Asio. In my other post I am proposing a library Boost.Buffers to work around this problem, so that people (like me) can write libraries which use only Asio buffer concepts, without a dependency on all of Asio (and everything that Asio depends on, recursively).
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. Another option, is just moving these concrete buffer classes from Asio to your new library, and then Boost.Asio will depend on Boost.Buffers. .
On Wed, Oct 4, 2017 at 7:51 AM, paul <pfultz2@yahoo.com> 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 concept.
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 made. 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: <https://github.com/vinniefalco/buffers/blob/30ef7031ec0909972a720c0cdd8d6c6e1cc9e37b/include/boost/buffers/asio.hpp#L13> 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.
On Wed, Oct 4, 2017 at 7:51 AM, paul <pfultz2@yahoo.com> 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.
There's another solution that we spit-balled, it is this: using const_buffer = std::pair<void const*, std::size_t>; using mutable_buffer = std::pair<void*, std::size_t>; Now ConvertibleToConstBuffer just means convertible to std::pair<void const*, std::size_t> which is a plain std:: type. This also would require a paper to change Networking-TS. What do you think? Thanks
participants (2)
-
paul -
Vinnie Falco