$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2025-04-22 23:03:37
On 23 Apr 2025 01:27, Aaron Graham via Boost wrote:
> I'd like to gauge the interest in adding the following library to boost:
> https://github.com/rokudev/rostd/blob/main/include/rostd/printx.hpp
>
> It's a simple library that checks and rewrites the format string at compile
> time in order to fortify it for use with printf, leaving the object code
> with only a call to the underlying C-standard printf-family function.
>
> It's a single header and requires C++20 or above (for cNTTP support).
> It contains these four functions: printf, sprintf, snprintf, fprintf
>
> These functions are used like so:
>
> Â Â printf<"Hello %s\n">("World!");
>
> Â Â char buf[20];
> Â Â sprintf<"Hello %s\n">(buf, "World!"); // yes, it's safe
>
> Â Â char buf[20];
> Â Â snprintf<"Hello %s\n">(buf, sizeof buf, "World!");
>
> Â Â fprintf<"Hello %s\n">(file, "World!");
>
> Features/rationale:
>
> * It provides old-style printf (supports all standard printf specifiers).
> * Fully type-safe. No format string attacks. Issues are found at compile time.
> * Length modifiers are deduced; these format strings are portable.
> Â (No PRIu64 inttypes stuff needed anymore, just use %u)
> * Adds %? format specifier (print whatever type is there).
> * Compiles to std::printf (much smaller object code than std::format).
> * Provides a way for developers to easily adapt this printf formatting
> Â capability to their own functions (logging, etc.)
>
> More detailed rationale is here:
> https://github.com/rokudev/rostd/blob/main/doc/printx.adoc
Seems like a neat lightweight alternative to std::format. Though the
documentation could better cover the comparison against std::format, in
particular wrt. compile times and binary sizes. I suspect, the question
of "why not just std::format" will be one of the most often asked.
Extensibility is also a point of interest. Lack of extensibility of
std::printf is often #1 reason why other alternatives are used. It would
be very much desirable if the proposed library tackled this limitation,
at least to some extent.