Date: Wed, 25 Oct 2023 22:52:16 +0200
Am Mittwoch, dem 25.10.2023 um 19:34 +0000 schrieb Niall Douglas via Liaison:
> Dear a subset of WG14,
>
> I've been asked to see what would be the general WG14 feelings towards
> an extension of the C preprocessor to enable implementation of
> F-strings. Here is the C++ focused draft paper:
>
> http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/hadrielk/cpp-proposals/main/f-string/f-string-r2.bs#c-usage
>
> What struck me reading this is that this would solve problems for C as
> well. To be specific, if I remember rightly some on WG14 would have
> concerns about `sprintf()` sufficiently that they might be open to
> seeing a proposed replacement. Off the top of my head, the format
> specification is running out of letters, execution speed is slow, and
> there are locale problems.
>
> All these C++ 20 addressed using `std::format()`. It occurs to me that
> if there were a compiler intrinsic `_FormatNString(const char *, ...)`
> which was a strict subset of `std::format()`, then via the C
> preprocessor extension proposed in that draft paper above you could do:
>
> ```
> int main(int argc, const char argv[]) {
> char buffer[256];
> for(int n = 0; n < argc; n++) {
> puts(_F(buffer, "arg {n}: {argv[n]}\n"));
> }
> return 0;
> }
> ```
>
> ... where the `_F()` macro induces the new feature.
>
> As under that paper, the C preprocessor would turn that into:
>
> ```
> int main(int argc, const char argv[]) {
> char buffer[256];
> for(int n = 0; n < argc; n++) {
> puts(_FormatNString(buffer, 256, "arg {}: {}\n", n, argv[n]));
> }
> return 0;
> }
> ```
>
> And then the compiler intrinsic `_FormatNString()` formats into the
> supplied char buffer the arguments. It would need to be a compiler
> intrinsic so the compiler statically knows the types needing formatting,
> thus substantially improving runtime performance and not needing type
> specifier letters.
>
> What are WG14 thoughts here? I ask because if WG14 were warm towards
> this type of replacement for `sprintf()`, that might direct the author
> to approach WG14 for implementing F-strings rather than WG21, as WG21
> would surely be loath to extend the C processor with C++ specific features.
A while ago I thought about having an option to continue a format
string after the last argument:
printf("a: %d %{", 4, "} b: %d %{", 5, "}\n");
This would solve the same problem without preprocessor changes,
but maybe a bit less elegantly.
Martin
> Dear a subset of WG14,
>
> I've been asked to see what would be the general WG14 feelings towards
> an extension of the C preprocessor to enable implementation of
> F-strings. Here is the C++ focused draft paper:
>
> http://api.csswg.org/bikeshed/?url=https://raw.githubusercontent.com/hadrielk/cpp-proposals/main/f-string/f-string-r2.bs#c-usage
>
> What struck me reading this is that this would solve problems for C as
> well. To be specific, if I remember rightly some on WG14 would have
> concerns about `sprintf()` sufficiently that they might be open to
> seeing a proposed replacement. Off the top of my head, the format
> specification is running out of letters, execution speed is slow, and
> there are locale problems.
>
> All these C++ 20 addressed using `std::format()`. It occurs to me that
> if there were a compiler intrinsic `_FormatNString(const char *, ...)`
> which was a strict subset of `std::format()`, then via the C
> preprocessor extension proposed in that draft paper above you could do:
>
> ```
> int main(int argc, const char argv[]) {
> char buffer[256];
> for(int n = 0; n < argc; n++) {
> puts(_F(buffer, "arg {n}: {argv[n]}\n"));
> }
> return 0;
> }
> ```
>
> ... where the `_F()` macro induces the new feature.
>
> As under that paper, the C preprocessor would turn that into:
>
> ```
> int main(int argc, const char argv[]) {
> char buffer[256];
> for(int n = 0; n < argc; n++) {
> puts(_FormatNString(buffer, 256, "arg {}: {}\n", n, argv[n]));
> }
> return 0;
> }
> ```
>
> And then the compiler intrinsic `_FormatNString()` formats into the
> supplied char buffer the arguments. It would need to be a compiler
> intrinsic so the compiler statically knows the types needing formatting,
> thus substantially improving runtime performance and not needing type
> specifier letters.
>
> What are WG14 thoughts here? I ask because if WG14 were warm towards
> this type of replacement for `sprintf()`, that might direct the author
> to approach WG14 for implementing F-strings rather than WG21, as WG21
> would surely be loath to extend the C processor with C++ specific features.
A while ago I thought about having an option to continue a format
string after the last argument:
printf("a: %d %{", 4, "} b: %d %{", 5, "}\n");
This would solve the same problem without preprocessor changes,
but maybe a bit less elegantly.
Martin
Received on 2023-10-25 20:52:23