no net::buffer() overload accepts const basic_string

[jwakely]

const std::string s = "";
net::buffer(s);

This fails because the buffer(basic_string_view<C,T>) overload cannot deduce its template arguments.

We could add overloads for string_view, wstring_view, u16string_view and u32string_view but that's not helpful for generic code using unusual specializations of basic_string.

Probably better to add overloads for const basic_string

[chriskohlhoff]

Overloads for const basic_string added in 252903978b37cf90a0feec78cd85143f23da23da.

Leaving open for further discussion.

[mclow]

Leaving it open is good; I have some ideas about string_view/string interoperability that I'm hoping to circulate in Kona.

[breese]

There is something about buffers in general that is bothering me (amplified by the addition of dynamic_buffer.)

While I recognized the need for the DynamicBuffer concept, and in fact find that it can be useful in other contexts, I am bothered by the fact that I need to wrap my containers in this or that buffer before passing it to an operation. For instance, I currently need to do

std::string content;
socket.read(net::dynamic_buffer(content));

whereas I would much rather be able to do this:

std::string content;
socket.read(content);

This could be done by adding a trait (or policy) to wrap the buffer, and then have specializations for std::string, std::string_view, std::vector, etc. The implementation of socket::read() could then use the trait to find the appropriate buffer type.

If the trait is made public, then we could have support for user-defined buffers as well.

For inspiration, I have an example of such a trait for a parser/generator project, where the trait::buffer_type maps from the user-supplied container to the wrapper class.