I get the feeling author would just like to use a better language, like F# or Ocaml, and completely misses the point what makes C++ valuable.<p>C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program (usually you end up with figuring out the best memory layout and utilization).<p>C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards.<p>C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc).<p>I simply don't understand what type of industrial use this type of theoretical abstraction building serves.<p>Using the metaprogramming features makes code bases extremly hard to modify and they don't actually protect from a category of runtime errors. I'm speaking from experience.<p>I would much rather have a codebase with a bit more boilerplate, a bit more unit tests and strong integration testing suite.<p>The longer I use C++ the more I'm convinced something like Orthodox C++ is the best method to approach the language <a href="https://bkaradzic.github.io/posts/orthodoxc++/" rel="nofollow">https://bkaradzic.github.io/posts/orthodoxc++/</a><p>This keeps the code maintainable, and performant (with less effor than metaprogramming directed C++).<p>Note: the above is just an opinion, with a very strong YMMV flavour, coming from two decades in CAD, real time graphics and embedded development.
As someone that had the option to choose between C and C++, coming from compiled BASIC and Object Pascal backgrounds, back in the early 1990's.<p>What makes C++ valueable is being a TypeScript for C, born in the same UNIX and Bell Labs farm (so to speak), allowing me to tap into the same ecosystem, while allowing me to enjoy the high level abstractions of programming languages like Smalltalk, Lisp, or even Haskell.<p>Thus I can program on MS-DOS limited with 640 KB, an ESP32, Arduino, a CUDA card, or a distributed system cluster with TB of memory, selecting which parts are more convinient for the specific application.<p>Naturally I would like in 2025 to be able to exercise such workflows with a compiled managed language instead of C++, however I keep being in the minority, thus language XYZ + C++ it is.
C++20 inverts the traditional relationship between the core language and metaprogramming, which arguably makes it new language in some ways. Instead of being a quirky afterthought, it has become the preferred way to interact with code. There is a point of friction in that the standard library doesn’t (and can’t) fully reflect this change.<p>Metaprogramming style in C++20 only has a loose relationship to previous versions. It is now concise and highly maintainable. You can do metaprogramming in the old painful and verbose way and it will work but you can largely dispense with that.<p>It took me a bit to develop the intuitions for idiomatic C++20 because it is significantly different as a language, but once I did there is no way I could go back. The degree of expressiveness and safety it provides is a large leap forward.<p>Most C++ programmers should probably approach it like a new language with familiar syntax rather than as an incremental update to the standard. You really do need to hold it differently.
As someone that has only dabbled in C++ over the past 10 years or so, it feels like each new release has this messaging of “you have to think of it as a totally new language”. It makes C++ very unapproachable.
As someone that has been using C++ extensively for the last 25 years, each release has felt as an incremental improvement. Yes, there are big chunks in each release that are harder to learn, but usually a team can introduce them at their own pace.<p>The fact that C++ is a very large and complex language and that makes it unapproachable is undeniable though, but I don't think the new releases make it significantly worse. If anything, I think that a some of the new stuff does ease the on-ramp a bit.
I only which concepts were easier, those of use that don't use C++ daily have to look the expression syntax all the time, much better than the old ways I guess.
> C++ is valuable, because the existing tooling enables you to optimize the runtime peformance of a program<p>This is true for MANY other languages too, I don't see how this makes c++ different. With gdb its quite the opposite, handlig c++ types with gdb can be a nightmare and you either develop your own gdb glue code or write c-like c++.<p>> C++ is valuable becaus it's industry support guarantees code bases live for decades _without the need to modify them_ to latest standards.<p>In times of constant security updates (see the EU's CRA or equivalent standards in the US) you always gotta update your environment which often also means updating tooling etc. if you don't wanna start maintaining a super custom ecosystem.<p>I don't see this as a positive in general, there is bit rot and a software that is stuck in the past is generally not a good sign imo.<p>> C++ is valuable because the industry tooling allows you to verify large areas of the program behaviour at runtime (ASAN etc).<p>Sanitizers are not C++ exclusive too and with rust or C# you almost never need them for example. Yes C++ has extensive debugging tools but a big part of that is because the language has very few safeguards which naturally leads to a lot of crashes etc..<p>I think the idea of using only a small subset of C++ is interesting but it ignores the problem that many people have, you don't have the time to implement your own STL so you just use the STL. Ofc it gives me more control etc. but I'd argue most of the time writing orthodox c++ won't save time even in the long run, it will save you headaches and cursing about c++ being super complicated but in the end in modern environments you will just reinvent the wheel a lot and run into problems already solved by the STL.
> handlig c++ types with gdb can be a nightmare and you either develop your own gdb glue code or write c-like c++.<p>That's why better to use lldb and it's scripts.<p>> I think the idea of using only a small subset of C++ is interesting but it ignores the problem that many people have, you don't have the time to implement your own STL so you just use the STL.<p>Yeah, agree. It's just much easier to take a "framework" (or frameworks) where all the main problems solved: convenient parallelism mechanisms, scheduler, reactor, memory handling, etc. So it's turning out you kinda writing in your own ecosystem that's not really different from another language, just in C++ syntax.
orthodox C++ should be a subset of C++, I would really use it, like if there was a compiler flag<p>I can imagine it might be insanely faster to compile
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.<p>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.<p><a href="http://en.cppreference.com/w/cpp/io/println.html" rel="nofollow">http://en.cppreference.com/w/cpp/io/println.html</a><p>Here's what the article argues:<p>> 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.<p>Solid remark, and the consensus on how std::printnl and std::format are an important improvement over std::cout or C's printf.
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,<p>> Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.<p>and has a code example of what they argue 'Orthodox C++' should be, which uses printf.<p>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'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.<p>Compare to <iostream>, which is stateful and slow.<p>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.<p>I would not use iostreams, but neither would I use printf.<p>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.<p>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.
The biggest issue with printf is that it is not extensible to user types.<p>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.<p>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).<p>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.<p>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.