On Wed, Oct 4, 2017 at 7:51 AM, paul
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/30ef7031ec0909972a720c0cdd8d6c6e... 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.