> For small-to-medium text files, I read the entire thing into memory in
one read() call and scan with regular expressions.

Yes, I was referring mostly to this scenario. The problem I have is that
"one read() call" does not have a nice API. In many applications the
problem to deal with is simply loading a config file and parse. Assuming
some reasonable (and parameterized) limit on the file size, it should not
be that cumbersome to load it into a std::string for further processing. Or
maybe a class like this one would do:

struct file {
file(const std::filesystem::path& location);
std::string read(size_t limit = 4096U);
std::string readline();
...
};

My point is it seems to be quite common to write this by hand one way or
another and yet C++ still lacks a nice API for that. It is a shame that
Python has a lot better RAII interface in this area than C++ :)

On Mon, 6 Nov 2023 at 01:00, Chris Gary via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> For small things, I've ended up wrapping POSIX streams in a class that
> really just exists to close() them. For text output on such things, it was
> a derived type that used snprintf into an std::vector<char> line buffer.
> For a new project today, if I absolutely had to use the standard library,
> I'd go with std::format_to with std::back_inserter( bfr ) (bfr being
> vector<char> or whatever would work), then just write the bfr after each
> call. You can also come up with some analogue of back_inserter that does an
> "auto-flush" with bfr.
>
> For small-to-medium text files, I read the entire thing into memory in one
> read() call and scan with regular expressions.
>
> I don't have any example ideas for console input, since any such tools I
> end up writing don't need to prompt for further input after their
> invocation.
>
> <iostream> has been broken performance-wise for a long time, sadly. I
> think the entire thing could use a refactor, and that might involve
> actually once-and-for-all separating locale & text processing from stream
> manipulation (which I feel would be a good thing here, honestly).
>
> On Sun, Nov 5, 2023 at 12:37 PM Grzegorz Sikorski via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> This question may be old and probably has already been answered before,
>> but I cannot find any references. Was there ever considered adding to the
>> standard a simple text file manipulation API (better performing and less
>> cumbersome to use than std::fstream)? Read/write file from/to std::string
>> is a common operation and whenever I need to write a piece of code like
>> that it does not look nice plus there is a dispute about std::fstream
>> performance penalty when compared to C-style fopen/fclose. I would like
>> to have an API (possibly new overloads like below):
>> std::string fread(const std::filesystem::path& infile);
>> size_t fwrite(const std::filesystem::path& outfile, const std::string&
>> outstr);
>>
>> I am probably oversimplifying (there should probably be some extra
>> parameters, defaulting to something most useful), but this is just to
>> better show what I have in mind.
>>
>> Thanks,
>> Greg
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>