4 Aug
2023
4 Aug
'23
5:55 a.m.
Hi Dan,
On 2023-08-03 23:29, Dan Cross wrote:
I think you mean absl::StrFormat(). It has printf(3)-like syntax, so
I can't say say much against it. I don't know the details of how they
achieved the claimed 2x ~ 3x performance compared to snprintf(3). I'm
curious to know if it's an inherent limitation of snprintf(3), or if
it's just that glibc is very unoptimized --which is true anyway, because
no-one has really maintained the printf(3) code in a long time--.
It's interesting, because then std::format() is not that miraculous
compared to snprintf(3).
Isn't a variable format string a security vulnerability? Where do you
need it?
Thanks,
Alex
On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar
<alx.manpages(a)gmail.com> wrote:
Being in POSIX.1 it's portable to most (all?) current systems. ISO C
is a baseline for an implementation. A quality implementation will
go beyond that standard (or will be rather useless). POSIX.1 is more
of a useful thing.
But yeah, we can remove that "'" to get the idea.
On 2023-08-03 19:51, John Cowan wrote:
One issue is that this isn't standard C: the `'` verb for grouping by
thousands is an SUSv2 extension. I just checked the latest C23 draft,
and unless I missed it, it doesn't appear to have made it in.
On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar
<alx.manpages(a)gmail.com>
wrote:
But if speed is not a problem, I'd keep the good ol' syntax that
everybody knows. No need to make everybody learn a "cool" new print
I didn't claim that there's never a reason to invent new syntax. My claim
was rather that in this case, there isn't.
- printf(3) is more powerful than any other existing formatting function
that I know of any language --I'm still curious of what's the equivalent
of "%+'0#8.5f" in other formatting functions--.
function, that probably won't be as tunable
as printf(3) is.
By that argument, there would be no C, only Algol 68 and PL/I, or subsets
of them.
But things like that are fairly straight-forward in many other
languages. For example, in Go, the format string is nearly identical,
modulo the `'`:
Yup; I like go in that sense.
[...]
- It is also reasonably fast (at least for such
a highly-customizable
formatting function), and I'd like to see any system beat that while
keeping the customizability.
At Google, a group of exceptionally talented engineers wrote a
replacement in C++ for both type safety and because, bluntly, `printf`
(actually `snprintf`) was too slow. I believe the overall mechanism
made it into ABSL.
- It is type-safe, with the right tools.
No it's not, and it really can't be. True, there are linters that can
try to match up types _if_ the format string is a constant and all the
arguments are known at e.g. compile time, but C permits one to
construct the format string at run time (or just select between a
bunch of variants); the language gives you no tools to enforce type
safety in a meaningful way once you do that.