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
constexpr
from 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++
- 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
That is clearly wrong. If there is no unique_ptr, you won't use pointers at all and you will write your own class for RAII. unique_ptr creates a mess of abusing them instead of writing your own class.
That is your opinion on whether it is stupid or not.
People who added those things have the same reasons as "yours":
Those facts are proven in a lot of other languages.
Still, adding a feature that another language has is a very bad reason.
It forces a tax on people who do not need format string due to the runtime bloat. This violates the first part of the zero-overhead principle. You do not pay for what you do not use.
I can always do better by hand. This violates 2nd part of the zero-overhead principle
Yes, the truth is that it is inapplicable to C++. Same with std::format. Because those runtime parsing features are direct violations of the zero-overhead principle. Plus there are whiners in wg21 who just want to put locale everywhere. If they do not try to solve the fundamental issue which is to deprecate iostream and replace it with something else. Those features will forever be issues.
That is NOT great at all. Since C++ does not have destructive move semantics, applying things like [[clang::trivial_abi]] will silently cause use-after-free due to mess up with the order of destructions. That has been explained by Chandler in cppcon2019. The fundamental problem is the language is poorly designed which makes those things happen in the first place.
https://youtu.be/rHIkrotSwcc?t=2379
About EH, That is clearly false. C++ EH is a trillion-dollar historical mistake.
https://youtu.be/I_ffAFzi-7M
There are environments the deterministic of EH is extremely important. Like real-time systems.
C++ EH is a direct violation of the zero-overhead principle due to binary bloat and hurt on optimizations.
https://www.youtube.com/watch?v=ARYP83yNAWk
C++ EH is ridiculous slow to the point you should absolutely ban it. It is 100x slower than syscall. Using exception handling == denial of service since the attacker can just send invalid data to make your server keep throwing EH and hitting denial of service EXTREMELY quick.
Optimizations to EH solve nothing. You still need a dynamic allocation to throw and some sorts of RTTI to catch.
C++ EH is also extremely hard to implement. You still do not solve the issues in a lot of environments where you do not have EH implemented. I just recently compile C++ code to wasm and then use wasm2lua to translate wasm to lua. Do you think Lua is going to provide an EH mechanism as C++ does? That is impossible to implement.
https://youtu.be/_1Dob0kb8pw
https://youtu.be/_1Dob0kb8pw
C++ EH is a historical mistake and design failure.
Why would fast_io check any of them contain ${jndi:address}? It just prints data dude. ${jndi:address} itself is a format string. That is exactly format string vulneralbility.
fast_io NEVER parses format string. Completely immune to any issues like this.