fmt

bit flags. Which is absolutely horrendous when dealing with file I/O: It hides away the underlying error with no proper way to access it. - Deep class hierarchy making the entire thing looks like spaghetti. - Useless abstraction with stringstream that hides the underlying buffer away, making it close to unusable on embedded safety critical systems where memory allocations are forbidden. All of that made <iostreams> aged pretty badly, and for good reasons. Fortunately there is an incoming way out of that with work of Victor Zverovich on std::format and libfmt [1]. [1]: https://github.com/fmtlib/fmt

hile the <print> and <format> headers that people make such a fuss about, don't even seem available on gcc nor clang on my fully updated debian bookworm system. The reason is that those implementations aren't complete, even though <format> is C++20. The recommended way to get those headers is to grab https://github.com/fmtlib/fmt as an external library... Talk about the level of hype and lack of pragmatism that's going on around here. People are accusing each other for not using a standard library that isn't even implemented in compilers... And with a likelyhood they haven't used the external library themselves, and given that this library is external it's not heavily tested and probably contains bugs still, maybe CRASHES and SECURITY EXPLOITS. But let me test C++ features that actually exist: #if VERSION == 0 #include <iostream> #include <streambuf> struct membuf: std::streambuf { membuf(char *p, size_t size) { setp(p, p + size); } size_t written() { return pptr() - pbase(); } }; int main() { char buffer[256]; membuf sbuf(buffer, sizeof buffer); std::ostream out(&sbuf); out << "Hello " << 42 << "\n"; fwrite(buffer, 1, sbuf.written(), stdout); return 0; } #elif VERSION == 1 #include <sstream> #include <iostream> void test(std::stringstream& os) { os << "Hello " << 42 << "\n"; } int main() { std::stringstream os; test(os); std::cout << os.str(); return 0; } #elif VERSION == 2 #include <stdio.h> int test(char *buffer, int size) { int r = snprintf(buffer, size, "Hello %d\n", 42); return r; } int main() { char buffer[256]; int len = test(buffer, sizeof buffer); fwrite(buffer, 1, len, stdout); return 0; } #endif Compile & link: CT LT TT PT PL -DVERSION=0 0.361s 0.095s 0.456s 0.081s 32573 -DVERSION=1 0.364s 0.089s 0.453s 0.074s 32338 -DVERSION=2 0.039s 0.088s 0.127s 0.031s 918 CT=compile time, LT=link time, TT=total time (CT+LT), PT=preproc time (gcc -E), PL=preprocessor output lines Bench script: # put -DVERSION=1 or -DVERSION=2 as cmdline arg time clang++ -c "$@" -Wall -o test.o test.cpp time clang++ -Wall -o test test.o time clang++ "$@" -Wall -E -o test.preprocessed.txt test.cpp wc -l test.preprocessed.txt My clang version here is 14.0.6. I measured with g++ 12.2.0 as well and the results were similar (with only 50% of the link time for the snprintf-only version). For such a trivial file, the difference is ABYSMAL. If we extrapolate to real programs we can assume the difference in build times to be 5-10x longer for a general change in programming style. Wait 10 seconds or wait 1 minute. For a small gain in safety, how much are you willing to lose? And how much do this lost time and resources actually translate to working less on the robustness of the program, leaving more security problems (as well as other problems) in there? And talking about lost run time performance, that is real too if you're not very careful. > For snprintf(), how do you ensure that your format string and variadic arguments will not cause crash at runtime? The C++ version is compile-time type safe. Honestly I just don't ensure it perfectly -- beyond running them once as described. I write a lot of code that isn't fully proofed out from the beginning. Exploratory code. A few printfs are really not a concern in there, there are much bigger issues to work out. I also absolutely do have some printfs that were quickly banged out but that are hidden in branches that have never actually run and might never happen -- they were meant for some condition that I'm not even sure is possible (this happens frequently when checking return values from complicated APIs for example). The real "problem" isn't that there is a possibly wrong printf in that branch, but that the branch was never tested, and is likely to contain other, much worse bugs. But the fact that the branch was never run also means I don't care as much about it, pragmatically speaking. Likely there is an abort() or similar at the end of the branch anyway. It's always important to put things into perspective like that -- which is something that seems often missing from C++ and similar cultures. The more proofed out some code gets, the more scrutiny it should undergo obviously. Apart from that, compilers do check printfs, and I usually get a warning/error when I made a mistake. But I might not get one if I write my own formatting wrappers and am too lazy to explicitly enable the checking.

nt and println.