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.
Back in late 1990 we were also modern-at-the-time C++ hipsters, and we used latest features. We told everyone also they should use those features too. Over time we learned it's unnecesary to use some language features just because they are there, or features we used proved to be bad (like RTTI, exceptions, and streams), or it backfired by unnecessary code complexity. If you think this is nonsense, just wait few more years and you'll hate Modern C++ too ("Why I don't spend time with Modern C++ anymore" archived LinkedIn article).
Code base written with Orthodox C++ limitations will be easer to understand, simpler, and it will build with older compilers. Projects written in Orthodox C++ subset will be more acceptable by other C++ projects because subset used by Orthodox C++ is unlikely to violate adopter's C++ subset preferences.
#include <stdio.h>
int main()
{
printf("hello, world\n");
return 0;
}
- C-like C++ is good start, if code doesn't require more complexity don't add unnecessary C++ complexities. In general case code should be readable to anyone who is familiar with C language.
- Don't do this, the end of "design rationale" in Orthodox C++ should be immedately after "Quite simple, and it is usable. EOF".
- Don't use exceptions.
Exception handling is the only C++ language feature which requires significant support from a complex runtime system, and it's the only C++ feature that has a runtime cost even if you don't use it – sometimes as additional hidden code at every object construction, 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 anyway, so you don't even get to know that you didn't forget to handle some error case! And on a stylistic note, the exception style of error handling doesn't mesh very well with the C style of error return codes, which causes a real schism in programming styles because a great deal of C++ code must invariably call down into underlying C libraries.
- Don't use RTTI.
- Don't use C++ runtime wrapper for C runtime includes (
<cstdio>,<cmath>, etc.), use C runtime instead (<stdio.h>,<math.h>, etc.) - Don't use stream (
<iostream>,<stringstream>, etc.), use printf style functions instead. - Don't use anything from STL that allocates memory, unless you don't care about memory management. 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.
- Don't use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity.
- Wary of any features introduced in current standard C++, ideally wait for improvements of those feature in next iteration of standard. Example
constexprfrom C++11 became usable in C++14 (per Jason Turner cppbestpractices.com curator)
Due to lag of adoption of C++ standard by compilers, OS distributions, etc. it's usually not possible to start using new useful language features immediately. General guideline is: if current year is C++year+5 then it's safe to start selectively using C++year's features. For example, if standard is C++11, and current year >= 2016 then it's probably safe. If standard required to compile your code is C++17 and year is 2016 then obviously you're practicing "Resume Driven Development" methodology. If you're doing this for open source project, then you're not creating something others can use.
UPDATE As of January 14th 2022, Orthodox C++ committee approved 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++
- The Defold engine code style
- 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
Totally agree with that. VTables are performance killer, yet people in C++ keep crying about Garbage Collectors. No, child, GC isn't what made Java slow, it was the excessive use of Heap and Virtual Calls. You do that in C++ and you get slow code. You don't use virtual calls and inheritance and excessive object orientation in C# (or Java), and it goes fast as hell when the JIT kicks on.
But you take OCaml with a GC and it isn't slow, (not until you misuse closures, which go on heap)
Also, C++ has no "0-cost" abstractions, because abstractions have mental costs. Nothing in C++ is free of cost, CPU time is cheap, but Brain time is not.
Sometimes I want performance, so that's why I use C++, but mostly I get that performance from tightly coupling to whatever library is that I use and was made with C++ and then doing LTO. (one day GraalVM will kill that feat and then I won't have any reason to use C++, because I can glue any C library to any higher level language without any interop cost, that thing is true engineering marvel)
Memory management hardly matters much, I got here because of a discussion on allocators. How it is allocated and freed doesn't matter, the layout of the memory matters, which is why we use C++.
But then there's STL to bork everything.
Want to go fast, just transpose your Array of Objects into an Object of Arrays, and then it doesn't matter if you use a GC because the Object is going to be allocated with its millions of elements all contiguous (*1). Then the only thing that matters is alignment to the cache lines, but can you control that with C++ ? no, so what's the point even.... of manual memory management ?
(*1) (its just one allocation, and one free, which divided by millions of elements makes the cost of any automatic memory management almost free)
Fortran only had arrays and that was good enough. Pointers are kind of an abstraction leak from the underlying hardware architecture, I don't think there's place for pointer arithmetic in higher level language, or do you guys like to do manual bank switching too ?