user-provided overloads of buffer_size intended? about networking-ts HOT 7 CLOSED

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.

from networking-ts.

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?

from networking-ts.

Good talk :)

from networking-ts.

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.

from networking-ts.

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

from networking-ts.

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

from networking-ts.

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).

from networking-ts.