53454879 839a6480 39dd 11e9 9915 41baca494461

Orthodox C++ | Branimir Karadžić’s Home Page

by

This article was originally published as an abstract here.

What is Orthodox C++?

Orthodox C++ (sometimes also called C+) is a minimal subset of C++ that improves C, but avoids all the unnecessary things from so-called modern C++. This is the exact opposite of modern C++.

Why not modern C++?

In the late 1990s we were also trendy C++ hipsters at the time, and we used the latest features. We also told everyone that they should also use those facilities. Over time we learned that it was unnecessary to use certain language features simply because they existed, or the features we used turned out to be bad (like RTTI, exceptions, and streams), or it backfired by causing unnecessary code complexity. If you think this is nonsense, just wait a few more years and you’ll hate modern C++ too (“Why I don’t spend time with modern C++ anymore” archived LinkedIn article).

d0pfbigxcaeip0m

Why use orthodox C++?

“Within C++, there’s a much smaller and cleaner language fighting its way out.” – Bjarne Stroustrup

A code base written with orthodox C++ constraints will be easier to understand, simpler, and will be built with older compilers. Projects written in the Orthodox C++ subset will be more accepted by other C++ projects because the subset used by Orthodox C++ is not likely to violate the adopter’s C++ subset preferences.

Hello World in Orthodox C++

#include 

int main()
{
    printf("hello, world\n");
    return 0;
}

What should I use?

  • C-like C++ is a good start, don’t add unnecessary C++ complexities if the code doesn’t need much complexity. In general the code should be readable to anyone familiar with the C language.
  • Don’t do this, in orthodox C++ the end of “design rationale” should be immediately followed by “simple enough, and it’s usable”. eof“.
  • Don’t use exceptions.

Exception handling is the only C++ language feature that requires significant support from a complex runtime system, and it is the only C++ feature that has a runtime cost, even if you don’t use it – sometimes in the form of extra hidden code on every object creation, destruction, and try block entry/exit, and always by limiting what the compiler’s optimizer can do, often quite significantly. Yet C++ exception specifications are not enforced at compile time, so you don’t even realize you forgot to handle some error case! And on a stylistic note, the exception style of error handling does not match very well with the C style of error return code, which causes a real divide in programming styles because a large portion of C++ code will always call into the underlying C libraries.

  • Do not use RTTI.
  • Do not use C++ runtime wrappers for C runtime (, etc), use the C runtime instead (, etc.)
  • Do not use stream (, etc), use printf style functions instead.
  • Don’t use anything from the STL that allocates memory, unless you care about memory management. See CppCon 2015: Andrei Alexandrescu “What’s std::allocator for allocation, what’s std::vector for unwrapping” discussion, and why many AAA gamedev studios run out of STL threads for more info.
  • Don’t overuse metaprogramming for academic masturbation. Use it sparingly, only where necessary, and where it reduces code complexity.
  • Be wary of any features introduced in current standard C++Ideally wait for those features to be improved in the next iteration of the standard. Example constexpr Became usable in C++11 to C++14 (According to Jason Turner cppbestpractices.com Curator).
  • Do not use the module.

Using modules brings with it the following disadvantages:

  1. Your code needs to be rewritten (possibly refactored).
  2. Loss of portability.
  3. Module binary files (with the exception of MSVC) are not portable so you need to provide header files for the libraries in any case.
  4. Project build setup becomes more complex.
  5. No toolchain versions work except the latest (Apple’s module support is listed as “partial” at the time of writing)

In return for all this, you, the regular developer about the city, get the following benefits:

  1. Nothing.

Is it safe to use any of modern C++? Features yet?

It is usually not possible to start using new useful language features immediately due to the delay in adoption of the C++ standard by compilers, OS distributions, etc. The general guideline is: If the current year is C++Year+5 so it’s safe to start selective using c++YearFeatures of. For example, if the standard is C++11, and the current year is >=2016 then it is probably safe. If the standard required to compile your code is C++17 and the year is 2016 then obviously you are practicing the “resume driven development” methodology. If you’re doing this for an open source project, you’re not creating something that other people can use.

Revision History

update As of January 14, 2025, the Orthodox C++ Committee approved selective use of C++20.

Any other similar ideas?

code example





<a href

Leave a Comment