Orthodox C++ (sometimes referred to as C+) is the minimal subset of C++ that improves upon C but avoids all unnecessary elements of so-called Modern C++. It stands in direct opposition to what Modern C++ is supposed to represent.
Back in the late 1990s, we were also modern-at-the-time C++ hipsters, using the latest features and advocating for their widespread adoption. However, over time, we learned that it's unnecessary to utilize certain language features simply because they exist. Some features we once championed, like RTTI, exceptions, and streams, proved to be detrimental, leading to unnecessary code complexity. If you think this perspective is nonsensical, just wait a few more years, and you'll likely find yourself disenchanted with Modern C++ too (archived LinkedIn article).
A codebase adhering to Orthodox C++ limitations will be easier to understand, simpler, and will build with older compilers. Projects written within the Orthodox C++ subset are more likely to be accepted by other C++ projects, as this subset is unlikely to violate adopters' C++ subset preferences.
#include <stdio.h>
int main()
{
printf("hello, world\n");
return 0;
}- C-like C++ is a good starting point. If code doesn't require additional complexity, avoid adding unnecessary C++ complexities. In general, code should be readable to anyone familiar with the C language.
- Don't do this, In Orthodox C++, the end of "design rationale" should immediately follow "Quite simple, and it is usable. EOF".
- Refrain from using exceptions.
Exception handling is the only C++ language feature that requires significant support from a complex runtime system. It's the only C++ feature that incurs a runtime cost even if you don't use it, sometimes adding additional hidden code at every object construction, destruction, and try block entry/exit. Moreover, it limits what the compiler's optimizer can do, often quite significantly. Yet C++ exception specifications are not enforced at compile time anyway, so you don't even get to know if you've forgotten to handle some error case. Additionally, on a stylistic note, the exception style of error handling doesn't mesh well with the C style of error return codes, causing a real schism in programming styles because much C++ code inevitably calls down into underlying C libraries.
- Avoid using RTTI.
- Refrain from using C++ runtime wrappers for C runtime includes (, , etc.); instead, use the C runtime (<stdio.h>, <math.h>, etc.).
- Avoid using streams (, , etc.); opt for printf-style functions instead.
- Avoid anything from the STL that allocates memory unless memory management is of no concern. See CppCon 2015: Andrei Alexandrescu "std::allocator Is to Allocation what std::vector Is to Vexation" talk, and Why many AAA gamedev studios opt out of the STL thread for more info.
- Avoid excessive metaprogramming for academic purposes. Utilize it only where necessary to reduce code complexity.
- Be cautious of features introduced in the current standard C++. Ideally, wait for improvements to those features in the next iteration of the standard. For example, constexpr from C++11 became more usable in C++14 (per Jason Turner cppbestpractices.com curator)
Due to the lag in adoption of the C++ standard by compilers, OS distributions, etc., it's usually not advisable to start using new, useful language features immediately. A general guideline is: if the current year is C++year+5, then it's likely safe to start selectively using the features introduced in C++year. For example, if the standard is C++11, and the current year is 2016 or later, then it's probably safe. If the standard required to compile your code is C++17 and the year is 2016, then obviously you're practicing "Resume Driven Development" methodology. If you're doing this for an open-source project, then you're not creating something others can use.
UPDATE: As of January 14th, 2022, the Orthodox C++ committee approved the use of C++17.
- Embedded C++
- Nominal C++
- Sane C++
- Why Your C++ Should Be Simple
- C++, it’s not you. It’s me.
- "Keep It C-mple" Alexander Radchenko Sydney C++ Meetup
- A dialect of C++
- Any C source that compiles with C++ compiler.
- DOOM 3 BFG
- Qt (when built with no-rtti, no-exceptions)
- dear imgui
- bgfx
- TheForge
- Oryol
- Network Next SDK