Date: Sun, 5 Nov 2023 17:00:42 -0700
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
>
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
>
Received on 2023-11-06 00:00:54