东正教C ++

正统C ++（有时称为C +）是C ++的最小子集，可改进C，但避免了所谓的Modern C ++中的所有不必要的事情。它与现代C ++的假设完全相反。

早在1990年代末，我们还是当时的C ++潮人，我们使用了最新功能。我们还告诉所有人，他们也应该使用这些功能。随着时间的流逝，我们了解到不必仅仅因为存在某些语言功能就使用它们，或者我们证明所使用的功能不好（例如RTTI，异常和流），或者由于不必要的代码复杂性而适得其反。如果您认为这是胡说八道，那就再等几年，您也会讨厌Modern C ++（为什么我不再花时间在Modern C ++上了，已归档的LinkedIn文章）。

具有Orthodox C ++局限性的代码库将更易于理解和简化，并且将使用较早的编译器进行构建。用Orthodox C ++子集编写的项目将被其他C ++项目更接受，因为Orthodox C ++使用的子集不太可能违反采用者的C ++子集首选项。

如果代码不需要更多的复杂性，则不要添加不必要的C ++复杂性，否则，类似于C的C ++是一个好的开始。通常，熟悉C语言的任何人都应该可以阅读代码。

不要这样做，设计原理的结尾。在Orthodox C ++中应该非常简单地立即使用，并且可以使用。 EOF＆＃34;。

异常处理是唯一的C ++语言功能，需要复杂的运行时系统的大力支持，并且它是唯一的C ++功能，即使您不使用它，也要花运行时成本–有时作为附加的隐藏代码每个对象的构造，销毁和尝试块的进入/退出，并总是通过限制编译器的优化器可以做的事情来完成，通常非常重要。但是无论如何在编译时都不会强制执行C ++异常规范，因此您甚至不知道自己没有忘记处理某些错误情况！从风格上讲，错误处理的异常样式与错误返回代码的C样式无法很好地融合在一起，这在编程样式中引起了真正的分裂，因为大量的C ++代码必须始终调用底层代码C库。

不要使用C ++运行时包装程序，因为C运行时包含（＆lt; cstdio＆gt ;、＆lt; cmath＆gt;等），请改用C运行时（＆lt; stdio.h＆gt ;、＆lt; math.h＆gt;等）

除非您不关心内存管理，否则请不要使用STL中分配内存的任何内容。

不要在学术手淫中过度使用元编程。仅在必要时并在降低代码复杂性的地方适度使用它。

警惕当前标准C ++中引入的任何功能，最好等待下一次标准迭代中对这些功能的改进。来自C ++ 11的示例constexpr在C ++ 14中变得可用（根据Jason Turner cppbestpractices.com策展人）

由于编译器，OS发行版等都没有采用C ++标准，因此通常无法立即开始使用新的有用语言功能。一般准则是：如果当前年份为C ++ year + 5，则可以安全地有选择地开始使用C ++ year的功能。例如，如果standard是C ++ 11，并且当前年份＆gt; = 2016，那么它可能是安全的。如果编译代码所需的标准是C ++ 17，年份是2016，那么显然您正在练习“简历驱动开发”。方法。如果您是针对开源项目执行此操作，那么您就不会创建其他人可以使用的东西。