4 Aug
2023
4 Aug
'23
3:29 a.m.
On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar <alx.manpages(a)gmail.com> wrote:
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.
But things like that are fairly straight-forward in many other
languages. For example, in Go, the format string is nearly identical,
modulo the `'`:
: prithvi; cat print.go
package main
import "fmt"
func main() {
fmt.Printf("%+0#8.5f\n", 3.1415)
}
: prithvi; go run print.go
+3.14150
: prithvi;
Type safety is achieved through reflection.
In Rust, which has a very pleasant formatted print facility, type
safety is handled by implementing `print` and `println` as macros. I
don't miss `printf` there.
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.
- 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.
I can understand the need for less-customizable faster
formatting functions
for very-high-performance programs, and std::format may fit well there. But
other than that, I don't see a reason to invent so many different formatting
functions. Of course, one may do that just for fun, in which case I applaud
that. But printf(3) is superior to them, IMO.
That sort of relative value judgement can be difficult to justify
without specifying the criteria that goes into one's judgement. As you
said, it is an opinion and that's fine, but opinions vary. :-)
- Dan C.