Orthodox C++

周五 17 十二月 2021

本文翻译自https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b，原作者是Бранимир Караџић。

什么是Orthodox C++？

Orthodox C++（有时被称为C+）是C++的最小子集，它改进了C，但避免了所谓的现代C++中所有不必要的东西。它与现代C++的预设恰好相反。

为什么否定现代C++?

在1990年末，我们也是当时的现代C++潮人，我们会用最新的功能。我们告诉大家就应该用这些特性。随着时间的推移，我们搞清了使用一些语言特性其实是大可不必的，这很明显，我们用的特性已经被证明是不好的（像RTTI、异常和流），非必要的代码复杂性搞得适得其反。如果你认为这是无稽之谈，那就再多等几年，到时你也会讨厌现代C++（LinkedIn的归档文章：《为什么我不再花时间研究现代C++了》）。

一副漫画

为什么要用Orthodox C++？

基于Orthodox C++限制所编写的代码，将更容易理解，更简单，并且可以用更老的编译器构建。用Orthodox C++子集编写的项目，将更容易被其他C++项目接受，因为Orthodox C++用到的子集，不太会与采用者的C++子集偏好相冲突。

使用Orthodox C++编写的Hello World

    #include <stdio.h>

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

我该使用什么？

类C的C++是个好的开始，如果代码不需要更多的复杂性，就不要增加不必要的C++复杂性。一般情况下，代码对于熟知C语言的人来说，应该是可读的。
不要做这事，Orthodox C++“设计原理”的结尾，应该紧跟“很简单，且可用。EOF”。
不要使用异常。

异常处理是唯一的需要复杂的运行时系统支撑的C++语言特性，也是唯一的即使你不用也要付出运行时消耗的C++特性——很多时候，它会在每个对象的构造、析构以及try块的进入/退出时，额外地加入隐藏代码，还总是很大地限制编译器能做的优化。然而，C++的异常又是编译期是不执行的，所以你甚至不知道是否忘了处理一些错误的情况！从风格上看，处理错误的异常，与C的错误返回码风格并不匹配，这导致了编程风格的真实分裂，因为C++代码必然会调用底层C库。

不要使用RTTI。
不要使用被C++运行时包装的C运行时，包括（<cstdio>、<cmath>等），要使用C运行时（<stdio.h>、<math.h>等）。
不要使用流（<iostream>、<stringstream>等），使用printf风格的函数代替。
不要使用任何由STL分配的内存，除非你不关心内存管理。详见CppCon 2015：《std::allocator归于分配，std::vector归于纠结》（Andrei Alexandrescu）这个讲座，以了解更多信息。
不要过度使用元编程来进行学术自慰。要适度，只在必要时，在能降低代码复杂度时，使用它。
对当前的标准C++<年份>中引入的任何特性，要有警惕性，最好等到这些特性在标准的下一次迭代中得到了改进。例如，C++11中的“constexpr”待到C++14中再采用（来自Jason Turner，cppbestpractices.com的站长）。

使用现代C++<年份>的功能都还安全吗？

由于编译器、操作系统发行版等，对C++标准采用的滞后。通常不能立即开始使用那些新的、有用的语言特性。一般性指导是：如果今年是C++年份+5，就可以安全地开始有选择性地使用C++_年份_的特性。例如，如果标准是C++11，而今年>=2016，则基本是安全的。如果编译你的代码需要的标准是C++17，并且今年是2016年，那么显然你是在实践“简历驱动开发”方法论。如果你在做开源项目，那你就不是在造别人能用的东西。

更新截至2019年1月14日, Orthodox C++委员会已认可对C++14的使用。

还有其他类似的想法？

代码示例

任何被C++编译器通过的C源码
DOOM 3 BFG
Qt (使用无RTTI、无异常构建的)
dear imgui
bgfx
TheForge
Oryol
Network Next SDK

funcman's blog