Orthodox C++, sometimes called C++, is a minimal subset of C++ that improves upon C but avoids all unnecessary elements of modern C++ Orthodox C++ is the opposite of what modern C++ should be

Orthodox C++, sometimes called C+, is a minimal subset of C++ that improves on C but avoids all the unnecessary stuff of so-called modern C++. This is the exact opposite of what Modern C++ You should be.

Why not modern C++?

In the late 1990s, we were modern C++ hipsters, using the latest features. We told everyone that we should use these features too. Over time, we learned that we didn’t need to use certain language features just because they existed, or that the features we were using were bad (like RTTI, exceptions, and streams), or that they turned against us by making the code unnecessarily complex. If you think that’s absurd, wait a few more years and you will also hate modern C++ (Why I don’t spend time with modern C++ anymore, archived article).

Why use Orthodox C++?

A code base written with the constraints of orthodox C++ will be easier to understand, simpler and compatible with older compilers. Projects written in the Orthodox C++ subset will be better accepted by other C++ projects, because a subset using Orthodox C++ is unlikely to violate the adopter’s C++ subset settings.

Hello to the world with Orthodox C++

1
2
3
4
5
6
7
8
 
#include <stdio.h>
 
int main()
{
    printf("hello, world\n");
    return 0;
}

What should I use?

C++ close to Cu is a good start, if the code doesn't require more complexity, don't add unnecessary C++ complexity. In general, the code should be readable by anyone familiar with the C language.
do not do that, the end of the design rationale in Orthodox C++ should be right after It's pretty simple, and it's usable. EOF.
Do not use exceptions.

Exception handling is the only feature of the C++ language that requires significant support from a complex runtime system, and it's the only feature of C++ that has runtime costs even if you don't use it - sometimes as extra hidden code for every object construction and destruction, and every attempt block I/O, and always limiting what the compiler optimizer can do, often quite significantly. However, C++'s exception specifications aren't enforced during compilation anyway, so you can't even know if you've forgotten to handle an error case! Stylistically, the exception handling style does not fit very well with the C style of error return codes, causing a real rift in programming styles because much of the C++ code must always call the underlying C libraries.
Do not use RTTI.
Do not use a C++ runtime wrapper for C runtime includes (, etc.), use the C implementation instead (, etc.).
Do not use feed (, etc.), use printf-like functions instead.
Don't use anything from the STL that allocates memory unless you care about memory management. See CppCon 2015: Andrei Alexandrescu "std::allocator is to allocation what std::vector is to perturbation" (https://www.youtube.com/watch?v=LIb3L4vKZ7U), and Why are many AAA gamedev studios opting out of the STL threadfor more information.
Do not overuse metaprogramming for the purpose of academic masturbation. Use it sparingly, only when necessary and when it reduces code complexity.
Be careful with features introduced in the current C++ standard, ideally wait until these features are improved in the next iteration of the standard. For example, constexpr from C++11 which became usable in C++14 (by Jason Turner cppbestpractices.com curator)

Is it safe to use modern C++ features?

Due to delays in the adoption of the C++ standard by compilers, operating system distributions, etc., it is usually not possible to start using new, useful features of the language right away. The general rule is: if the current year is C++year+5, it is possible to run selectively using C++ featuresyear. For example, if the standard is C++11 and the current year >= 2016, there is probably no danger. If the standard required to compile your code is C++17 and the year is 2016, you are obviously practicing the Resume Driven Development methodology. If you're doing this for an open source project, then you're not creating something that others can use.

On January 14, 2022, the Orthodox C++ Committee approved the use of C++17.

Other similar ideas?

Code examples
source: orthodox C++

and you

What do you think ?

Do you find the orthodox C++ guidelines credible or relevant?