From: Gavin Lambert (boost_at_[hidden])
Date: 2020-03-11 06:35:00
On 11/03/2020 14:17, Vinnie Falco wrote:
> "streambuf" is far too heavyweight to use as a low-level interface. I
> already pointed out that a codec needs to have as arguments not only
> the input and output "spans" but also return the number of bytes
> transacted for input and output.
>
> signal-to-noise in this discussion is low...in a sense, zlib gets the
> crux of it right with the z_params:
>
> struct z_params
> {
> void const* next_in;
> std::size_t avail_in;
> std::size_t total_in = 0;
> void* next_out;
> std::size_t avail_out;
> std::size_t total_out = 0;
> int data_type = unknown; // best guess about the data type:
> binary or text
> };
>
> The question is, can we do better than this? I'm certain that all
> answers which boil down to "copy std stream APIs" are wrong.
std::streambuf is almost that straightforward in its storage (albeit it
uses more pointers, presumably related to supporting non-contiguous
streams or something).
(And boost::asio::streambuf uses it, which is typically Boost.Asio's
DynamicBuffer of choice.)
Other than Ye Olde Horrid Naming Conventions, the only particularly
heavyweight thing in it that I can see is the locale.
Would you like std::streambuf better if it omitted the locale? Or had
better naming conventions? Or is there some other objection to it?