cplusplus/networking-ts

user-provided overloads of buffer_size intended?

vinniefalco opened this issue · 7 comments

Is it intended that users can provide overloads of buffer_size for user-defined buffer sequence types? Is it something we should consider? I'm thinking about basic_streambuf and user defined alternatives, it can compute buffer_size for its input and output sequences in constant time.

We can consider whether we want it to be a customization point, but it currently isn't one. Paragraph 2 of Clause 4 [namespaces] means that references to buffer_size in the TS mean std::experimental::networking::v1::buffer_size, so program-defined overloads wouldn't be found by ADL.

N.B. if we want basic_streambuf to be usable as a buffer then we would need to provide a suitable overload ourselves in the TS, as it is undefined for the program to add an overload to namespace std.

N.B. if we want basic_streambuf to be usable as a buffer

Let me clarify. Types meeting the requirements of DynamicBuffer, such as basic_streambuf, define the "input area" and the "output area" which are themselves buffer sequences. So, the dynamic buffer is not the buffer sequence but rather, the two objects it provides. They are defined by the nested types const_buffers_type and mutable_buffers_type. For example:
https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/basic_streambuf.hpp#L122

I'm weakly in favor of having buffer_size as a customization point, since buffer_size for a beast::basic_streambuf::const_buffers_type or beast::basic_streambuf::mutable_buffers_type will have an execution time of O(N) where N is the number of buffers in its list:
https://github.com/vinniefalco/Beast/blob/master/include/beast/core/basic_streambuf.hpp#L74

With a customization point it could run in O(1):
https://github.com/vinniefalco/Beast/blob/master/include/beast/core/basic_streambuf.hpp#L242

Example implementation

template<class Allocator>
std::size_t
buffer_size(basic_streambuf<Allocator>::const_buffers_type const& cb)
{
    return cb.sb_->size();
}

On the other hand, I realize that I'm bringing this up rather late in the game and I don't want to create a bunch of unnecessary work for anyone. What are your thoughts?

Good talk :)

This will be submitted as a national body comment on the PDTS. I don't have a personal opinion on this topic and Github issues are not the right place to do design work, that needs to happen elsewhere and then be approved by the C++ committee.

This was submitted as a National Body comment against the PDTS, and discussed by the Library Evolution Working Group, see https://issues.isocpp.org/show_bug.cgi?id=300

This has become a performance issue for a company, I would like to revisit this - what is the procedure for doing so?

Via the WG21 committee. The recommended response to the NB comment is not to make a change at this time (i.e. for v1 of the TS). If you want to persuade them otherwise you need to talk to the committee (and I won't be present at the next meeting to do so on your behalf).