Date: Sun, 12 Mar 2023 22:41:26 -0700
On Sunday, 12 March 2023 17:05:32 PDT Robin Rowe via Std-Proposals wrote:
> > 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
>
> Interesting, Thiago. Why not?
Because the C standards committee is extremely conservative. If it has a tiny
chance of breaking people's code, they are unlikely to adopt it. They're even
rejecting constexpr functions for fear that compilation times will rise.
Given those two conditions, I expect the chance of such a change to one of the
most core functions in the standard passing through that committee is measured
in a percentage starting with 0.
> > What makes you think that it's a small change to printf?
>
> Am basing my thinking on the fact that modern C compilers warn on type
> mismatch in printf, even say what the type is and what the right flag
> would be.
You're discussing a compiler, not a library. printf() must be implementable as
a library function.
> > 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.
>
> No, often best to not replace working legacy C code with fresh C++ code
> to do the same thing. Too expensive.
Then why change anything at all? If your code was working with K&R printf, why
would they need your C++28 one? You need to give a motivation that includes
making changes in the first place.
> > what global lock?
>
> Am referring to the global new lock. Typically hidden in std::string
> when it calls new to create a string buffer.
There's no such thing.
> From experience, I know that iostream operations can be much slower
> than printf. In the past I have written my own iostream and string
> libraries that replace the std versions as a drop-in replacement to get
> the performance needed.
Yes, iostream can be much slower... and one of the reasons why it is often
slower is that it keeps in sync with C std buffers. If you were to turn that
off, they gain a bit more performance.
But we're not talking about iostreams. We're talking about std::print here.
> No, I haven't created my own fork of clang or gcc with a custom printf.
Don't modify the compiler.
If you can't implement this with existing C compilers, compile a lot of
existing C code and come to the answer "practically nothing broke", I doubt
the paper you'll publish to the C standards will get any attention.
> > 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
>
> Interesting, Thiago. Why not?
Because the C standards committee is extremely conservative. If it has a tiny
chance of breaking people's code, they are unlikely to adopt it. They're even
rejecting constexpr functions for fear that compilation times will rise.
Given those two conditions, I expect the chance of such a change to one of the
most core functions in the standard passing through that committee is measured
in a percentage starting with 0.
> > What makes you think that it's a small change to printf?
>
> Am basing my thinking on the fact that modern C compilers warn on type
> mismatch in printf, even say what the type is and what the right flag
> would be.
You're discussing a compiler, not a library. printf() must be implementable as
a library function.
> > 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.
>
> No, often best to not replace working legacy C code with fresh C++ code
> to do the same thing. Too expensive.
Then why change anything at all? If your code was working with K&R printf, why
would they need your C++28 one? You need to give a motivation that includes
making changes in the first place.
> > what global lock?
>
> Am referring to the global new lock. Typically hidden in std::string
> when it calls new to create a string buffer.
There's no such thing.
> From experience, I know that iostream operations can be much slower
> than printf. In the past I have written my own iostream and string
> libraries that replace the std versions as a drop-in replacement to get
> the performance needed.
Yes, iostream can be much slower... and one of the reasons why it is often
slower is that it keeps in sync with C std buffers. If you were to turn that
off, they gain a bit more performance.
But we're not talking about iostreams. We're talking about std::print here.
> No, I haven't created my own fork of clang or gcc with a custom printf.
Don't modify the compiler.
If you can't implement this with existing C compilers, compile a lot of
existing C code and come to the answer "practically nothing broke", I doubt
the paper you'll publish to the C standards will get any attention.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2023-03-13 05:41:29