On Thu, 4 May 2023 at 08:20, Jonathan Wakely <cxx@kayari.org> wrote:


On Thu, 4 May 2023, 05:18 Simon Hill, <protogrammer@gmx.com> wrote:
There's constexpr-cleverness going on in the format-string evaluation, so the generated binary code shouldn't (given a decent compiler and well written header code) be any larger or slower for users who don't use "%s", nor should the runtime libraries be affected. You can see this by the fact an invalid format string fails at compile time instead of runtime, that you can't pass a non-constexpr format string, and that the changes only need be made in a header with no runtime library rebuild.

I know, I wrote the GCC implementation you're using :-)

What your observations actually show is that the format string is checked for validity at compile-time, using a consteval function to verify its syntax is valid. But if you use std::vformat instead of std::format, there is no such checking. And the compile-time checking is just checking, there's no "compile a state machine from the format string" step that produces an optimized representation of the format string for use by std::format. So the actual formatting is not done at compile-time, and the format string is re-parsed at runtime.

And the fact you don't need to rebuild the runtime library is just because it's an inline function, not because everything is done at compile-time.