Hacker News Reader

Comment by gpderetta | Hacker News Reader

sorry, I can't take something that argues for "printf" in favour of anything else seriously.

> sorry, I can't take something that argues for "printf" in favour of anything else seriously.

I think you're arguing from a position of willful ignorance. The article is clear on how it lauds C++'s std::printnl, not printf.

http://en.cppreference.com/w/cpp/io/println.html

Here's what the article argues:

> With std::format, C++ has gained a modern, powerful, and safe formatting system that ends the classic, error‑prone printf mechanisms. std::format is not merely convenient but fully type‑safe: the compiler checks that placeholders and data types match.

Solid remark, and the consensus on how std::printnl and std::format are an important improvement over std::cout or C's printf.

I was referring to the Orthodox C++ article linked by parent. Of course format is an improvement on both printf and iostream.

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.

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.

_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.

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.

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.

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.

The article argues that modern C++ has type-checked string formatting, so it does not argue for (unchecked) `printf()`, right?

"The article" is ambiguous. The one this HN post is about does not argue for it, at all. But the one in the comment above directly says,

> Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.

and has a code example of what they argue 'Orthodox C++' should be, which uses printf.

I'm all for a more sensible or understandable C++, but not at the expense of losing safety. In fact I would prefer the other way: I still feel incredibly saddened that Sean Baxter's Circle proposal for Safe C++ is not where the language is heading. That, plus some deep rethinking and trimming of some of the worst edge behaviours, and a neater standard library, would be incredible.

I was indeed referring to the 'Orthodox C++ article'.

Reply on news.ycombinator.com