On Thu, Mar 14, 2019 at 5:09 PM Ivan Matek wrote:

Quite a weird pattern, where buffer does not have member begin, end. Maybe a sentence or two describing the rationale and complexity would be nice. I know it is O(1), but it is weird that begin/end are called on pointer.

Yeah, well... that's a sore subject. First of all I did not invent these buffer concepts, they are part of Asio and Networking TS. And they *used* to have begin() and end(), but then the C++ Standards Committee decided that they didn't like `const_buffers_1` and `mutable_buffers_1`, so they got rid of them in the TS draft. Then they realized that having `const_buffer::begin()` would be confusing. Does it refer to the beginning of the buffer sequence, or does it refer to the first byte of that buffer? They decided to get rid of begin/end entirely for the buffer types and add buffer_sequence_begin and buffer_sequence_end in its place. And this is why we can't have nice things.

std::size_t read_line I am tired, but is this function O(n^2)?

It starts over from the beginning of the range so there can be some overlap of the searching, yes.

cb += bytes_transferred; // adjust the pointer and size I would maybe switch to write instead of write_some to keep the code shorter, and mention write_some as another option in text.

Well the purpose of this example is to show the looping.

[](error_code ec, std::size_t bytes_transferred) For learning purposes I would capture something in lambda by value and note that reference capture would be buggy.

That is something I might consider!! Remember though I"m stuck in C++11 so no lambda capture assignment expressions. Appreciate the feedback! Regards

Hi, Am 15.03.2019 01:19, schrieb Vinnie Falco via Boost:

On Thu, Mar 14, 2019 at 5:09 PM Ivan Matek wrote:

...

Quite a weird pattern, where buffer does not have member begin, end. Maybe a sentence or two describing the rationale and complexity would be nice. I know it is O(1), but it is weird that begin/end are called on pointer.

Yeah, well... that's a sore subject. First of all I did not invent these buffer concepts, they are part of Asio and Networking TS. And they *used* to have begin() and end(), but then the C++ Standards Committee decided that they didn't like `const_buffers_1` and `mutable_buffers_1`, so they got rid of them in the TS draft. Then they realized that having `const_buffer::begin()` would be confusing. Does it refer to the beginning of the buffer sequence, or does it refer to the first byte of that buffer? They decided to get rid of begin/end entirely for the buffer types and add buffer_sequence_begin and buffer_sequence_end in its place. And this is why we can't have nice things.

Don't be sad :-) template <typename BufferSequenceType> class buffer_sequence_view { private: BufferSequenceType& sequence_; public: buffer_sequence_view(BufferSequenceType& s) : sequence_{s} {}; buffer_sequence_view(buffer_sequence_view& other) : sequence_{other.sequence_} {}; // ... auto begin() { return buffer_sequence_begin(sequence_); }; auto end() { return buffer_sequence_end(sequence_); }; // ... }; template <typename BufferType> class buffer_view { private: BufferType& buffer_; public: buffer_view(BufferType& b) : buffer_{b} {}; buffer_view(buffer_view& other) : buffer_{other.buffer_} {}; // ... auto begin() { return range::begin(buffer_.data()); }; auto end() { return range::end(buffer_.data()); }; // ... }; for( const auto& single_buffer : buffer_sequence_view(buffer_sequence) ) { // iterates over all elements of the buffer sequence ... } for( const auto& c : buffer_view(buffer) | view::take(42) ) { // iterates over the first 42 characters of a buffer (sequence) ... // I hope my interpretation of range::begin() and range::end() is correct; // this is completely untested. ;-) } So you can still have all the nice things with ranges based for loops, C++20 ranges, etc. Though I agree, that these views should be part of the standard. Otherwise everyone is going to implement them on their own with varying quality (you probably already have spotted some issues with my untested example code here), or even worse, works without them. Christof

Thank you for the reply, suggestions inline. On Fri, Mar 15, 2019 at 1:19 AM Vinnie Falco wrote:

And this is why we can't have nice things.

Somebody(tm) (ASIO or Beast) maybe should make buffer that has has member fn content() that returns a range with begin and end. example: if buffer is 8 bytes and you write 3 bytes buff.content().begin() would return .data() and content().end() would return .data()+3

...

std::size_t read_line I am tired, but is this function O(n^2)?

It starts over from the beginning of the range so there can be some overlap of the searching, yes.

I beg you to fix this by remembering the index of last find(I assume iterators are invalidated). I know in theory it is just an example, but people blindly c/p code, and to make matters worse this thing is hard to notice in tests since only very large total reads show O(n^2) behavior. regards, Ivan On Fri, Mar 15, 2019 at 1:19 AM Vinnie Falco wrote:

On Thu, Mar 14, 2019 at 5:09 PM Ivan Matek wrote:

...

Quite a weird pattern, where buffer does not have member begin, end. Maybe a sentence or two describing the rationale and complexity would be nice. I know it is O(1), but it is weird that begin/end are called on pointer.

Yeah, well... that's a sore subject. First of all I did not invent these buffer concepts, they are part of Asio and Networking TS. And they *used* to have begin() and end(), but then the C++ Standards Committee decided that they didn't like `const_buffers_1` and `mutable_buffers_1`, so they got rid of them in the TS draft. Then they realized that having `const_buffer::begin()` would be confusing. Does it refer to the beginning of the buffer sequence, or does it refer to the first byte of that buffer? They decided to get rid of begin/end entirely for the buffer types and add buffer_sequence_begin and buffer_sequence_end in its place. And this is why we can't have nice things.

...

std::size_t read_line I am tired, but is this function O(n^2)?

It starts over from the beginning of the range so there can be some overlap of the searching, yes.

...

cb += bytes_transferred; // adjust the pointer and size I would maybe switch to write instead of write_some to keep the code shorter, and mention write_some as another option in text.

Well the purpose of this example is to show the looping.

...

[](error_code ec, std::size_t bytes_transferred) For learning purposes I would capture something in lambda by value and note that reference capture would be buggy.

That is something I might consider!! Remember though I"m stuck in C++11 so no lambda capture assignment expressions.

Appreciate the feedback!

Regards