Orthodox C++ (2016)
bkaradzic.github.io for (auto const & ess : esses) {
...
}
Also, you can fight me if you want to take
dynamic_cast<Derived> (base_ptr)
Basically, stick with C and leave C++ programmers alone. I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.
C++ folks are very much into their language, and can't seem to understand that most folks don't want to dedicate significant amounts of mental resources purely to language details.
Regards, an embedded dev.
With time, the GCC developers acknowledged the benefits of using C++ over C, and migrated the code.
GCC requires a C++ compiler to bootstrap since around 2012, and GNU coding standards has been updated to several languages beyond C, time to go up with times.
D was implemented in "C with Classes" and then translated to D and bootstrapped. There isn't a line of C code in it.
Over time, we gradually replace the C-isms and C++isms and anachronisms in it to native D-isms.
The problems of the code I'm writing far exceeds the complexity of the language. Your complaint about complexity fall flat to me, unless you are working on a trivial program you need to deal with things far more complex than any language.
In the sense that C++ is complicated because it's C++, which is complicated? That's just a tautology. If you mean "the territory" in some other sense there's no reason to believe this.
And there lies the problem with C++: to be sure, you have to check. C++ code can't be taken at face value -- the most innocuous-looking code could be a ticking bomb.
You can't take C code at face value either. The name of a method or type doesn't tell you what it does. It could longjmp for all you know.
For Python, it's very little (nothing?). For Rust, you get more than most; lifetimes tell you whether it holds onto a pointer you give it.
Years ago, I was really proficient in C++, but after a year of programming in C#, I realized that not once had the behavior of my code caught me off guard. In the following years, I only ran into quirky behavior a couple of times. I could finally program without the constant mental overhead of watching out for C++ pitfalls.
Seems strange to talk down C++ while praising C#, which incidentally has been getting features to increase its use where Microsoft previously might have used C++ instead.
You catch pitfalls in any language the same way, using static analysis, which C authors introduced right in 1979, acknowledging the issues with language, which they decided to outsource to another tool, instead of improving the language.
A long tradition in computing.
I guess we'll have to agree to disagree here. And of course, even if C++'s user base seems to be shrinking, it still works well for some categories of programmers.
Swift, C#, Kotlin, Scala, Rust, Typescript, Python...
I went to some lengths with D to discourage such abusive operating overloading practice.
Slides:
For example, the standard says that adding elements to an <unordered_map> is not allowed to invalidate references to keys or elements within the map. That makes it impossible for any standards-compliant C++ implementation to use a high-performance implementation in which keys and elements are stored contiguously in a flat array.
The context of this thread is that someone stated that the C++ standard library sucks, and someone replied to them saying that it's just some implementations that suck, but that's separate from the language. The point I'm trying to make, in response, is that it is about the language. It's not just "some" implementations - there is no implementation of the C++ standard library that doesn't have these inefficiencies, because the language's own standard requires them.
(This is tangential but - this is why I often say that C++ is not actually the most complex language in the world, it's just over-specified. If you took almost any popular programming language and wrote a document dictating the behavior of every single feature and library to the same level of detail, you would end up with a document similar in length or even longer than the C++ standard.)
It's really hard to take your comment serious because of generalization like this. Maybe they're not usable for your particular usecase but that doesn't mean they suck. Just like there's a 'million' ways that C++ sucks in your book, there's a reason there's millions of lines of code out there where these containers are valid usecases and hence work without issues whatsoever nor a need to replace them with something else.
They're also unusable by the way because of ergonomic and software architecture factors, such as bad modularity, terrible compile times, unreadable error messages, unreadable symbol names...
Yes that is overgeneralizing a little bit but it's largely true.
The problem is typically not the containers themselves but all the other bad decisions that they push you to make in order to work around their "small issues".
The huge problem is that these containers can get you started quickly, i.e. leetcode type stuff and single threaded stuff, but at some point you'll realize your architecture ended up completely in the wrong place because of that.
If you haven't been thinking deeply about memory management and concurrency, you won't be able to understand, no offense meant. I've just fixed another subsystem that was completely overwhelmed, seeing 8x bandwidth gains already on a small testsystem, but the factor is basically unbounded when moving to bigger systems, when it's about contended vs uncontended.
Why is only 'high throughput, low frequency, massively concurrent work' considered 'serious'?
(Obviously I meant to say low latency, not low frequency)
The map stuff the other posters summed up well but even std::vector is dogshit with pretty much all implementations having inlined grow code in push_back, a not too great API and missed optimisations e.g. no trivial relocation when growing the vector / moving it and no useful APIs such as "grow but don't initialise"...
But already the basic premise that you should push back without thinking is wrong. You will suffer reallocations and invalisations when you least expected them, and frankly you have to architect around that fact which is a terrible restriction. You can work around by pre reserving but at that point it's just a basic fixed heap allocated array but worse because the type gives you a weird look all the time, "I'll realloc as soon as you don't pay attention, harhar"!
The implementation always tries to grow (if necessary) to the exact size chosen for Vec::reserve_exact, but for plain Vec::reserve if growth is needed it always grows exponentially, not to the exact size, preserving the O(1) push cost.
For a typical "doubling" growable array type, if we're pushing groups of ten items, reserve_exact or C++ grows like 10, 20, 30, 40, 50, 60, 70, 80, 90, 100 ... which is much worse than O(1) whereas the correct reserve grows 10, 20, 40, 80, 160 preserving O(1)
For trivial types you can work around this in C++ with a little work, and for the non-trivial types you can work around it with a bunch more extra code, but you probably won't.
Bjarne among other people teaching C++ recommend just not using the reservation API as a reservation API because of this problem†, and the resulting teaching definitely leaks into CS graduates and even into languages which have the correct API and so you have to un-teach the bad lesson.
In applications where you actually can't afford to pay for growth (or at least in some cases can't afford this) I also like Vec::push_within_capacity which I believe comes from Rust for Linux where the kernel legitimately needs this "If there's room push, otherwise I have a plan B" approach.
† To Bjarne this API is instead conceived of as a way to preserve reference validity. Since it won't grow, our references will still work.
1. arrays
2. linked lists
3. hash tables
4. simple binary trees
Only the really big ones, e.g. here is Emscripten's allocator that focuses on small binary size and is implemented in about 1.5 kloc (ignoring comments and whitespace it's actually under 1 kloc), and that allocator is perfectly fine for most use cases (especially C code bases which typically don't have a high allocation frequency):
https://github.com/emscripten-core/emscripten/blob/main/syst...
...and Seb Aaltonen's offset allocator (used for allocating GPU buffers in his Vulkan API wrapper) has under 500 lines of code:
https://github.com/sebbbi/OffsetAllocator/blob/main/offsetAl...
Right tool for the job etc... big general-purpose allocators like jemalloc or mimalloc are usually a bandaid to somewhat salvage a failed memory management strategy.
In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator.
I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.
And that utility library (there are dozens of them) is just as subject to debate and issues as libstdc++
I am not going to implement my own C versions of 90% of the stuff std:: provides, sorry.
As one example, I recently found templated lambdas useful in making animations.
Or if you're even lazier, you can easily make a more automatic RTTI system with some templates / macros that works much faster than dynamic_cast! (See https://github.com/royvandam/rtti)
E.g.:
https://github.com/floooh/oryol/blob/eb08cffe1b1cb6b05ed14ec...
(don't use that project though because it's been archived, I've switched back to plain old C in the meantime)
This is allowed by Orthodox C++
> dynamic_cast<Derived> (base_ptr)
This isn't because it requires RTTI, but dynamic_cast is also a typical code smell.
Orthodox C++ isn't generally against new C++ features, it only advices to wait about 5 years (or at least one C++ version) for stabilization and to apply some common sense before adopting them.
The notes about not using RTTI, exceptions and stdlib features that allocate under the hood are all justified by painful experience with those things in the context of game development.
In general, the restrictions outlined in the post make a lot of sense when considering that Branimir (of BGFX fame: https://github.com/bkaradzic/bgfx) is coming out of the game dev hemisphere, and from that PoV none of the restrictions are controversial - on the contrary, it would be highly controversial to suggest going all in on Modern C++ features ;)
I can see no rationale for this whatsoever. It is nothing but syntactic sugar.
> Branmir (of BGFX fame
Appeals to authority don't really work for me.
I've been writing a cross-platform DAW (0) for 25+ years, in C++, and what a game dev has to say about the language in their own work might be of passing interest but not much more.
Being aware of the pitfalls of particular features of a language is an important task for anyone programming in that language. But that doesn't mean that the language is fundamentally broken or that programmers cannot make their own choices about which features to use.
(0) on at least the same level of complexity as a modern game
Literally everyone who uses C++ decides which features to use/embrace and which to avoid. Someone sharing their particular preference is pretty normal and fine.
> Appeals to authority don't really work for me. I've been writing a cross-platform DAW (0) for 25+ years, in C++
I love how you reject appeal to authority and then try to establish yourself as an authority. That’s cute.
I wasn't seeking to establish my own authority in any way: "X is brilliant, we should listen to them" being countered by "there are lots of people with similar levels of experience with this thing who have many different opinions (I happen to be one of them)" isn't an appeal to authority. But sure, I could have left out the ("I happen to be one of them") part without changing my point much.
TFA is not about someone sharing their preferences. It's a direct call to not use many features, and claiming that to do otherwise is a mistake. Here's an example of sharing preferences:
"I've often tried to use C++'s variadic function templates, but I've found that just using initializer lists tends to be simpler and more readable".
Here's an example of how TFA would put that:
"do NOT use variadic function templates"
“I haven't seen a less useful article about C++ in a long time, and as an HN reader, that's really saying something.”
The tone of all your comments reads as oddly intense imho. Perhaps not your intent. Opinions may vary.
> TFA is not about someone sharing their preferences. It's a direct call to not use many features, and claiming that to do otherwise is a mistake
Yeah that’s fine. The whole piece is an opinion piece on what someone thinks is a good approach to C++ development. There is no value in hedging every single bullet point with a bunch of flourish imho.
In game dev C++ circles nothing in this list is particularly controversial. It’s just writing down what many/most devs already did.
The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know.
Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) but even that requires some extra action like moving the mouse over the definition and hoping it'll give you something. However this wont show up in diffs, PRs, code reviews, etc.
IMO `auto` is one of those C++ features that really needs discipline to use - and when in doubt, i'd rather ban its use (except where you cannot do otherwise) than rely on everyone doing the right thing.
Of course some discipline is required - as with just about everything in programming, especially in C++ - but developers in just about every other statically-typed language lean on type inference (including far more extensive type inference) and don't wring their hands about it. It's hard not to see this as a case of Blub - if you learned about typing with `Foo foo = new Foo()`, anything different might seem scary.
...anyway, in this case the real win probably is the range-based for loop, rather than the auto. `for (const Foo& foo : foos)` isn't so bad, but `for (std::vector<Foo>::const_iterator it = foos.begin(); it != foos.end(); ++it)` is pretty rough.
As important as the code to be readable.
> The odds are very good that it's clear from the context
As i wrote, if the actual type can be seen somewhere nearby (close enough to be included in diffs) then that's fine - it is already in the context. Though that is not usually the case and i personally had to work with code with which i was not familiar and which used `auto` all over the place and had to go hunting for the actual container declaration to see what it is (Visual Studio was not helpful in its tooltips).
So my actual experience is that i'd rather see the actual type.
However...
> anyway, in this case the real win probably is the range-based for loop
...yes, the range-based for loop is often the better choice when it comes to readability. And when compared with the iterators, it is pretty much always more readable than them :-P. `for (const Foo& foo : foos)` is basically what i'd prefer to see. It is the use of `auto` i pointed out.
Moreover, what's even more beautiful? You can change the type of things in the container "esses", and the code doesn't need to change.
If you have the experience, this construct tells you everything you need to know: it's an iteration over a container, visiting every element in order, without copying it, and without modifying it.
You don't need to know any more.
Yes, just use and IDE. This is a problem in Rust as well. And C#, Java, and others.
IMO you should use auto as much as possible. If the code can be written with auto, it should be. There’s no reason to repeat type definitions.
If you can use auto, what that means is the type is already statically known. C++ is a statically typed language; the compiler and tools know what type things are. So, just ask the tools, because they’re not wrong.
https://news.ycombinator.com/item?id=40445536 (2 years ago, 63 points, 66 comments)
https://news.ycombinator.com/item?id=25554018 (5 years ago, 70 points, 102 comments)
https://news.ycombinator.com/item?id=13751244 (9 years ago, 29 points, 14 comments)
Looks like the page was moved from a GitHub gist to a github.io page in October of last year.
Template metaprogramming is sometimes very useful to get around C++'s language restrictions, but I tend to use it sparingly.
With concepts and constexpr-if and consteval it's increasingly less of a problem
I'm curious what languages you're comparing to here. Feels like it's only slightly more expressive than pure generics, but I admittedly haven't done much template metaprogramming myself. How does it compare to, say, Zig's comptime?
On the other hand, if you control your own destiny and care about velocity and code quality, many of these choices eventually become self-evident.
If you are messing around with the latest and greatest esoteric C++ stuff in 2026, bless you, you beautiful nerd. But it may be time to start evaluating where you are in life, and how you got here. (And if you're on a C++ committee, I revoke those blessings.)
For those who remain: if you have a C++ code base yet somehow have enough time and energy to write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google.
Sounds like you hate exceptions, right? In which case why do you handle them at all? Just leave them all unhandled and suddenly every exception is a crash. Which is really no different from someone choosing to terminate. Which you have to worry about even without exceptions.
> if you have a C++ code base yet somehow have enough time and energy to write opinionated blog posts, it's really hard to imagine why you think you'd have a better take on this than Google.
"Given that Google's existing code is not exception-tolerant [...] Our advice against using exceptions is not predicated on philosophical or moral grounds, but practical ones. [...] Things would probably be different if we had to do it all over again from scratch."
If you std::abort(), you'll get a useful stack trace in the core dump. If you crash from an unhandled exception, you don't. That's a pretty huge difference and is one of the reasons exceptions suck.
If you're looking for implementation-specific guarantees then you could make that happen with exceptions too. I think on GCC replacing a function like __cxa_throw might be sufficient to let you capture a stack trace?
If you're looking for source-level-only guarantees then another option is to just replace your throw <expr> statements with one that attaches whatever extra info you want. You could literally script this to patch your external repos automatically too. Or heck, maybe you could even just define throw to be a macro that shoves your stack trace into some global variable before actually throwing.
All of this is up to the implementation in practice. The codebases I work on generally follow the pattern that exceptions may be thrown but may not be caught*, and thus they practically serve as terminate. And we absolutely get stack traces in our core dumps (Linux, both GCC and clang), and basically all of the complex debugging I do starts with a coredump stacktrace.
* We follow this pattern for a few reasons, (1) it is generally safer for us to assume that libraries we consume (STL included) will behave as expected with exceptions enabled, (2) "don't catch exceptions" (or if you must, catch the as close-to-throw as possible) is a simple way to avoid exceptions-for-nonexceptional-cases control flow, and (3) most of the C++ codebase is exposed through bindings in Python, and propagating errors as exceptions is the only Python-friendly way to handle it.
One of the problems with exceptions is it’s utterly impossible to know if a given function call can return exceptions and if so what they are.
My code DOES want to handle errors. Exceptions are, imho, a very very poor way to report errors.
Python is the bloody worst because I never effing know what the hell any damn function can throw or return. It’s so so frustrating.
Error handling is a hard and unsolved problem. But I’ll take Rust results over exceptions 10,000% of the time. Not even a question.
For example, you're implementing an arithmetic operator and have reached an erroneous state, but the arithmetic type doesn't have an error value, the only way to communicate the error is by throwing. Another example: you've specified that a function must always succeed, but later on you find a case where the function cannot succeed. Instead of fixing all the possible call sites, throw an exception. All those callers could not have handled the error anyway, because they were coded under the assumption that no error would happen at that point. Throwing an exception and letting it unwind the stack way up (perhaps even all the way up to main()) is the sensible solution, because at that point you've reached a situation with no reasonable way for that code to handle.
Saying that you prefer Result over exceptions is like saying that you prefer strings to functions. They do different things. If you like Result, nothing prevents you from implementing a C++ equivalent.
Maybe the tooling finally caught up.
Do you mean this as an appeal to Google being the home to great talent, or more as an endorsement of the specific guidance provided by this specific style guide, Google or no?
Because if the former, I think I do almost everything better in my context than Google would. It would be hard not to considering the difference in organizational scale.
> C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities.
C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).
> In general case code should be readable to anyone who is familiar with C language.
Most C++ already is? Even very template heavy C++.
> Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”.
A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.
> Don’t use exceptions.
Optional but irrelevant.
> Don’t use RTTI.
.. Why? Reimplementing RTTI in C will give you almost the same overhead.
> Don’t use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)
.. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include <stdio.h|xx>. Near 0 compiletime overhead?
> Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.
This is a design decision.
> Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity.
There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.
> A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.
So? Is your goal to make C++ shine, or is it to produce useful, understandable code? My goal is good code, not being a showoff.
In C, you can use goto to jump over a variable declaration, and you can't in C++. I understand why this is, but it's the thing I see the most often that makes C code not compile as C++.
It was the next step from Turbo Pascal in terms of safety, with added benefits from cross platform.
Nowadays all C compilers that matter are written in C++ anyway.
But, one of the annoying habits of WG21 (the C++ committee) is sending stuff to WG14 (the C committee) to have them make it part of their language rather than accept that it's a C++ problem. Even the stupid type qualifiers are actually C++'s fault, K&R doesn't have this abomination but the pre-standard C++ did so too bad now it's in C89.
And namespaces suck too, so much noise for little gain. You know what, a big part of programming is naming. You just have to come up with good names. Namespaces don't magically make names better, if anything, they make them worse. And they add a lot of syntax noise.
And I'm working on this project because the material removal simulation library that my company has been paying insane amounts of money for in the last 10 years just doesn't "cut" it for our grinding purposes (independently of the cruelfully bad C++ API, and the ~10x worse performance in their debug build because of all those dumb C++ objects inside), and it requires an insane amount of BS architecture around on our part to even use it, so I've concluded (after my own short periods of serious well-meaning suffering with this library on and off during the last 2 years), it should actually be way easier to make our own grinding simulation in a short time after running the numbers and concluding a realistic magnitude.
Guess what, I still see no reason why my little project shouldn't succeed, I've seriously come closer to realizing it, but COM Objects by Microsoft are once again not the reason why that is so. On the contrary, they are annoying to use (I'm not a newcomer to them), even though there are a lot of nice things to say about Microsoft APIs as well (and OpenGL should just die), it seems like a layer of bullshit to wade through for no obvious reason.
The nicest libraries in terms of usability have always been those with a simple & straightforward plain C interface.
It's a bit like concrete - there's two kinds (of programmers): the ones who have experienced namespace issues (i.e. name collisions) and the ones who haven't, yet.
For example, the Windows MFC framework had classes whose data members were all public. Some of reasons were;
1) MFC was a wrapper over lower-level Windows API/structs and therefore unnecessary getter/setter methods were avoided. The C++ class could be a simple wrapper over the underlying C-style POD.
2) The framework classes were supposed to be used by implementation inheritance to build one's skeleton application which led to tight coupling between base and derived classes. Hence the designers decided to make all members public which meant that users were not limited by any omissions in the basic design.
I actually used these ideas in a project where i implemented a C++ api over C state machines for H.323 protocols.
Smart pointers are good. People were doing them outside the standard in the late 90s.
Lambdas are a good feature.
I would sure love a good coroutine runtime, and first-class support for defer. You can do these manually, but language/toolchain/debugger support is nice to have.
(Pragmatically, I will be retired by the time they would be useful)
As far as avoiding things... avoid basically everything you don't need. Don't add language features that don't actually help you, just because they're there. Keep the subset you use small. But pick that subset to match your problem well, rather than out of dogma.
Being able to write "async" code essentially in-line is a superpower.
That's exactly how democratic governments make their decisions… you might think it's stupid, and you'd be right, but that's democracy. It's the majority that counts, not what's right. At least you can have a little fun with their arguments, they're pretty inventive you know.
Nim became the obvious choice, and I wasn't a fanboy before. Simple semantics, in a very functional style oriented around data's value. References and identity have to be trapdoored. Everything is single-owner unique lifetimes by default, no annotations or best-practices required. You end up writing extraordinarily functional/procedural code that produces very fast and memory-safe binaries, it fits right into C++'s niche.
The only objection I could steel man was that the standard library and most packages are composed of relatively pure functions that return new values, so allocations are happening there. But when types as complex as data frames can be semantically used as just values, and you know they have scoped lifetimes by default, the benefits are obvious.
With all of C++'s insanely specific, subtle, implicit, compiler- and platform-dependent behaviors, I've often wondered when the industry will finally consider its dominance an artifact of first-mover inertia and simply move on. There are vastly better ways to do all of the things it does, while easily exposing levers for the the things it's considered to do exceptionally well.
The problem of course is that no one agrees on which subset that is.
Printf/scanf are implemented as variadic functions without type checking and rely on the compiler to perform its own internal metaprogramming to inspect and warn about format mismatches.
Anyone advocating the use of the old cstdio as a primary design decision about which C++ language features to use is not serious.
No exceptions or RTTI make sense in an embedded system that needs to ensure determinism, but are arbitrary and unnecessarily hobbling for high-level systems and application programming. How do you do runtime method dispatch without creating vtables and RTTI from first principles? How do you propagate a runtime error deep from the bowels of a component all the way to some top-level event loop? The "orthodox" approach would be a mess of integer return codes with associated enums (and none of that enum class nonsense!). No Thanks. It's clear the author has no idea what he's talking about.
There are many more things to avoid than just iostream. HFT university has a good recap: https://hftuniversity.com/post/the-c-standard-library-has-be...
The point on exceptions I think is also misleading. Compilers typically make throwing an exception the expensive part, and the happy path inexpensive (not more expensive than a branch checking for errors, which should be the baseline for comparison, not an implementation with zero error checking.) So to say that they are "expensive" doesn't really make a useful argument.
And there are more things that could be done in this camp, like proposing a set of compiler flags, and a linter to enforce the subset you are subscribing to. Unfortunately the post offers none of that.
> <deque>: Needs a major performance overhaul", acknowledging that the standard's mandated block size is too small and the design needs to be rebuilt at the next ABI break
Except of course the standard does not mandate a block size. That's purely msvc picking a wrong block size and being stuck with it.
The rant about lists is also nonsense.
And why is the latter nonsense? lists have had terrible cache performance for decades now and vector is the better default choice of container.
But even "avoiding iostream" is stupid. The author presumably really means "avoid operator>> and operator<< for I/O". Even using type-safe printf-like stuff ultimately still sits on top of iostream.
> Orthodox C++ (sometimes referred as C+) is minimal subset of C++ that improves C, but avoids all unnecessary things from so called Modern C++. It’s exactly opposite of what Modern C++ suppose to be.
"Modern C++" is usually considered to mean the significant changes to the language in 2011, or 2011 and later. The thing is, that a "small subset improving over C", and without "unnecessary things" will not necessarily avoid 2011-and-later language features, and splurge with pre-2011 features. And this becomes clear as you read the recommendation. So, it's recommand to avoid:
* exceptions
* STL objects which allocate memory
* C++ streams
all C98 features. On the other hand, it's not recommended to avoid constexpr, and it is in fact hinted it is useful.
-----
C++ is a multi-paradigmatic language. It has lots of features, in the language and via the standard library. It is perfectly reasonable and legitimate to pick feautres which are well-tested enough; or well-regarded by, say, embedded or game developers, or doesn't seem too outlandish coming from C. Of course, different people will quibble over what exactly to adopt or discard, but I'm sure that different flavors of "orthodox C++", "sane C++", etc. are in fact used by many groups of developers.