Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk