const_buffer is a view
breese opened this issue · 4 comments
const_buffer [buffer.const] is a non-owning type that consists of a pointer and a size.
Consider renaming const_buffer to buffer_view partly to indicate that users must keep the underlying, owning buffer alive during operations that involve const_buffer, and partly for naming consistency with string_view.
In the same vein, it would make sense to rename mutable_buffer [buffer.mutable] to something like buffer_span. While there is no naming precedence for this in C++17, there are various span proposals (e.g. P0122R1 and P0123R1.)
Thanks for the suggestion. The latest draft has been sent to ISO as a PDTS now, so I'll raise this as a national body against the PDTS so that the committee considers it.
I'm just going to throw this out there - it sure would be nice if const_buffer::data and mutable_buffer::data returned a pointer to some sort of 8-bit quantity instead of a pointer to void. This would allow pointer arithmetic.
I forsee the use of const_buffer for much more than just networking operations. Its a great general purpose class. You could use it in a key/value database interface to pass buffers around. We have our own Slice class which works just like const_buffer, and we will switch to const_buffer when it appears in the standard. But data returning void* is really rather pointless. Returning std::uint8_t* would be a completely compatible change, and the return value would then have more utility.
some sort of 8-bit quantity
What if there is no such type on the host?
Returning std::uint8_t* would be a completely compatible change
No it wouldn't, because uint8_t is not guaranteed to exist, consider systems with 16-bit bytes.
As noted above there are various proposals for span types, and std::byte could be useful here. We can evaluate them for a v2 of this TS, or when moving these things into the main standard.
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=301