Rethinking C++: Architecture, Concepts, and Responsibility

Re:Rethinking C++: Architecture, Concepts, and Responsibility by jstimpfle on Tuesday November 25, 2025 @05:56AM (#46044630)

I'll bite. printf might be unsafe in terms of typing, in theory, but it's explicit and readable (with some caveats such as "PRIi32"). The actual chance of errors happening is very low in practice, because format strings are static in all practical (sane) uses so testing a single codepath will usually detect any programmer errors -- which are already very rare with some practice. On top of that, most compilers validate format strings. printf compiles, links, and runs comparatively quickly and has small memory footprint. It is stateless so you're always getting the expected results.

Compare to <iostream>, which is stateful and slow.

There's also std::format which might be safe and flexible and have some of the advantages of printf. But I can't use it at any of the places I'm working since it's C++20. It probably also uses a lot of template and constexpr madness, so I assume it's going to be leading to longer compilation times and hard to debug problems.

[ Parent | on HN ]

Re:Rethinking C++: Architecture, Concepts, and Responsibility by gpderetta on Tuesday November 25, 2025 @07:57AM (#46045352)

The biggest issue with printf is that it is not extensible to user types.

I also find it unreadable; beyond the trivial I always need to refer to the manual for the correct format string. In practice I tend to always put a placeholder and let clangd correct me with a fix-it.

Except that often clangd gives up (when inside a template for example), and in a few cases I have even seen GCC fail to correctly check the format string and fail at runtime (don't remember the exact scenario).

Speed is not an issue, any form of formatting and I/O is going to be too slow for the fast path and will be relegated to a background thread anyway.

Debugging and complexity has not ben an issue with std::format so far (our migration from printf based logging has been very smooth). I will concede that I do also worry about the compile time cost.

[ Parent | on HN ]

Re:Rethinking C++: Architecture, Concepts, and Responsibility by TinkersW on Tuesday November 25, 2025 @07:31AM (#46045187)

I my experience you absolutely must have type checking for anything that prints, because eventually some never previously triggered log/assertion statement is hit, attempts to print, and has an incorrect format string.

I would not use iostreams, but neither would I use printf.

At the very least if you can't use std::format, wrap your printf in a macro that parses the format string using a constexpr function, and verifies it matches the arguments.

[ Parent | on HN ]

Re:Rethinking C++: Architecture, Concepts, and Responsibility by jstimpfle on Tuesday November 25, 2025 @07:45AM (#46045268)

_Any_ code that was never previously exercised could be wrong. printf() calls are typically typechecked. If you write wrappers you can also have the compiler type check them, at least with GCC. printf() code is quite low risk. That's not to say I've never passed the wrong arguments. It has happened, but a very low number of times. There is much more risky code.

So such a strong "at the very least" is misapplied. All this template crap, I've done it before. All but the thinnest template abstraction layers typically end up in the garbage can after trying to use them for anything serious.

[ Parent | on HN ]

Re:Rethinking C++: Architecture, Concepts, and Responsibility by TinkersW on Tuesday November 25, 2025 @12:35PM (#46048267)

Error Log/assertions prints are by are the most likely code to have not been run prior. Some compilers type check printf, but not all.

[ Parent | on HN ]

Re:Rethinking C++: Architecture, Concepts, and Responsibility by surajrmal on Tuesday November 25, 2025 @10:44AM (#46046877)

I largely avoided iostream in favor of printf-like logging apis, but std::format changed my mind. The only hazard I've found with it is what happens when you statically link the std library. It brings in a lot of currency and localization nonsense and bloats the binary. I'm hoping for a compiler switch to fix that in the future. libfmt, which std::format is based on, doesn't have this problem.

[ Parent | on HN ]