Date: Sun, 12 Mar 2023 14:25:25 -0700
On Sunday, 12 March 2023 11:25:43 PDT Robin Rowe via Std-Proposals wrote:
> 1. Not practical to rewrite legacy C/C++ code containing a zillion
> printf statements.
True, but irrelevant and counterweighed. First, you need to weigh that against
the work that is required to get printf() to do what you're suggesting. I have
serious doubts it can even be made to do what you want in C, and if it's for
C++ only, then you'll have to justify why the standards team and the compiler
developers should spend time on printf for C++.
Second and most importantly, your statement is irrelevant. The zillions of
printf() statements are, in their vast majority, already working. No one is
going to go and touch them because we've got a new-fangled printf. If they are
using that in C++, at the next refactoring opportunity, they should update to
std::format and std::print, dispensing of the printf() code in the first place.
It stands to reason that any code able to benefit from C++29-newfangled-printf
has been able to benefit from std::print for longer.
And those that aren't strictly correct may still work for the purposes and
constraints they are found themselves in, so they may not be able to update to
the new API.
> 2. Building embedded systems and game servers, we may want to avoid
> std::string due to heap global lock.
Sorry, I don't buy this argument either.
First, you're comparing the cost of std::printf to the cost of FILE*. Both
have a cost, but you're making a judgement call here that one is preferable to
the other, without giving arguments as to why. I think printf() is allowed to
memory behind the scenes.
And if it can work without memory allocations and use only the already-
allocated stdout buffer, then why can't std::print do the same?
Second, what global lock? Maybe you should invest in a better memory allocator
instead? For an embedded system where the number of threads may be statically
know, it's perfectly possible to have a working malloc() without global locks.
Third, you're assuming that a type-safe C++ printf() would avoid the problem
you're alluding to, but again you don't prove that. At a minimum, you'd have
to show that this implementation is possible-easy for std::printf() and
unliekly-difficult to std::print().
> It's not that we lack more modern approaches for type-safe printing such
> as std::iostream, std::format or std::print. It's that a small change to
> printf could make legacy code maintenance and embedded systems
> development better.
What makes you think that it's a small change to printf? Have you actually
implemented it and proven that it is so?
If so, please provide a link to your repository with the proof of concept.
> 1. Not practical to rewrite legacy C/C++ code containing a zillion
> printf statements.
True, but irrelevant and counterweighed. First, you need to weigh that against
the work that is required to get printf() to do what you're suggesting. I have
serious doubts it can even be made to do what you want in C, and if it's for
C++ only, then you'll have to justify why the standards team and the compiler
developers should spend time on printf for C++.
Second and most importantly, your statement is irrelevant. The zillions of
printf() statements are, in their vast majority, already working. No one is
going to go and touch them because we've got a new-fangled printf. If they are
using that in C++, at the next refactoring opportunity, they should update to
std::format and std::print, dispensing of the printf() code in the first place.
It stands to reason that any code able to benefit from C++29-newfangled-printf
has been able to benefit from std::print for longer.
And those that aren't strictly correct may still work for the purposes and
constraints they are found themselves in, so they may not be able to update to
the new API.
> 2. Building embedded systems and game servers, we may want to avoid
> std::string due to heap global lock.
Sorry, I don't buy this argument either.
First, you're comparing the cost of std::printf to the cost of FILE*. Both
have a cost, but you're making a judgement call here that one is preferable to
the other, without giving arguments as to why. I think printf() is allowed to
memory behind the scenes.
And if it can work without memory allocations and use only the already-
allocated stdout buffer, then why can't std::print do the same?
Second, what global lock? Maybe you should invest in a better memory allocator
instead? For an embedded system where the number of threads may be statically
know, it's perfectly possible to have a working malloc() without global locks.
Third, you're assuming that a type-safe C++ printf() would avoid the problem
you're alluding to, but again you don't prove that. At a minimum, you'd have
to show that this implementation is possible-easy for std::printf() and
unliekly-difficult to std::print().
> It's not that we lack more modern approaches for type-safe printing such
> as std::iostream, std::format or std::print. It's that a small change to
> printf could make legacy code maintenance and embedded systems
> development better.
What makes you think that it's a small change to printf? Have you actually
implemented it and proven that it is so?
If so, please provide a link to your repository with the proof of concept.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-03-12 21:25:27