游戏编程的C++ -爱还是不信任？

Question

以游戏编程效率的名义，一些程序员不信任多个C++特性。我的一位朋友声称了解游戏产业的运作方式，并提出以下几点意见：

• 不要使用智能指针。游戏里没人会这么做。
• 在游戏编程中，对于内存和速度，异常不应该(而且通常不是)使用。

这些陈述中有多少是真实的？C++特性的设计考虑到了效率。这样的效率不足以进行游戏编程吗？97%的游戏编程？

C思维方式似乎仍然对游戏开发社区有很好的把握.这是真的吗？

我又看了一段关于GDC 2009多核编程的视频。他的演讲几乎完全面向Cell编程，在处理之前需要DMA传输(简单的指针访问不能与Cell的SPE一起工作)。他不鼓励使用多态性，因为指针必须是DMA传输的“重新基础”。太让人伤心了。就像回到广场一样。我不知道是否有一个优雅的解决方案来编程C++多态性的细胞。DMA传输的话题是深奥的，我在这里没有太多的背景。

我同意，C++对那些希望使用一种小语言、而不想阅读成堆书籍的程序员来说也不是很好。模板也把调试吓跑了。你同意游戏界对C++的恐惧吗？

Answer 1

听着，你听到的关于编程效率的每一件事都是魔法思维和迷信。智能指针确实有性能开销；特别是当您在内部循环中执行许多花哨的指针操作时，它可能会产生不同的效果。

也许吧。

但是当人们说这样的话时，通常是因为很久以前就有人告诉他们X是真的，除了直觉之外，什么都没有。现在，细胞/多态问题听起来似乎是合理的--我敢打赌，对第一个这么说的人来说是这样的。但我还没核实。

您将听到关于操作系统中的C++的相同说法:它太慢了，它做了一些您希望做得很好的事情，非常糟糕。

尽管如此，我们构建的OS/400 (从v3r6向前)完全在C++，裸金属向上，并有一个快速，高效，小的代码库。这需要一些工作，特别是裸金属的工作，有一些自举的问题，使用新的布局，诸如此类的事情。

C++可能会成为一个问题，仅仅因为它太大了:我现在正在重读Stroustrup的断路器，这是相当可怕的。但是，我不认为有任何固有的东西说你不能在游戏编程中有效地使用C++。

Answer 2

我最后一次玩的游戏是PS3上的“天剑”，它是用C++写的，甚至是用单元代码写的。在此之前，我做了一些PS2游戏和个人电脑游戏，他们也是C++。没有使用智能指针的项目。不是因为任何效率问题，而是因为通常不需要这些问题。游戏，特别是控制台游戏，在正常播放期间不使用标准内存管理器进行动态内存分配。如果有动态物体(导弹、敌人等)，那么它们通常是预先分配并根据需要重复使用的。每种类型的对象都会对游戏所能处理的实例数有一个上限。这些上限将被定义为所需的处理量(太多，游戏会慢到爬行)或RAM的数量(太多，您可能会频繁地开始分页到磁盘，这会严重降低性能)。

游戏通常不使用异常，因为游戏不应该有bug，因此不能产生异常。这尤其适用于游戏机制造商测试游戏的控制台游戏，尽管最近的360和PS3等平台似乎有一些游戏可能会崩溃。老实说，我没有在网上读到任何关于启用异常的实际成本的文章。如果只在抛出异常时才会产生成本，那么就没有理由不在游戏中使用它们，但我不确定，它可能取决于所使用的编译器。一般来说，游戏程序员知道什么时候会出现问题，可以在业务应用程序中使用异常来处理(比如IO和初始化)，并在不使用异常的情况下处理它们(这是可能的！)

但是，在全球范围内，C++作为一种游戏开发语言正在逐渐减少。Flash和Java的市场份额可能要大得多，它们确实有异常和智能指针(以托管对象的形式)。

至于Cell指针访问，当代码以任意基址的DMA方式进入单元时，就会出现问题。在这种情况下，代码中的任何指针都需要用新的基址“固定”，这包括v表，而且您并不想对加载到Cell中的每个对象都这样做。如果代码总是加载在一个固定的地址，那么根本就不需要修改指针。但是，您会失去一些灵活性，因为您限制了代码的存储位置。在PC机上，代码在执行过程中从不移动，因此不需要在运行时进行指针修复。

我真的不认为任何人‘不信任’C++特性--不信任编译器是另一回事，而且常常是新的，深奥的体系结构，如C++，往往比C++编译器更容易获得健壮的C编译器，因为C编译器比C++编译器容易得多。

Answer 3

如果你或你的朋友真的偏执于性能，那就去看看英特尔的优化手册。有趣的。

否则，每次都要追求正确性、可靠性和可维护性。我宁愿玩慢一点的游戏，也不愿有撞车的游戏。如果/当您注意到您有性能问题时，配置文件，然后优化。您可能会发现，有一些热点代码可以通过使用更有效的数据结构或算法来提高效率。当分析显示它们是唯一值得加速的方法时，只会为这些愚蠢的微型优化而烦恼。

所以：

1. 编写代码要清楚和正确
2. 配置文件
3. PROFILE
4. 您能使用更有效的数据结构或算法来加速瓶颈吗？
5. 使用微优化作为最后的手段，并且只有在分析表明这会有所帮助的情况下。

PS:许多现代C++编译器提供了异常处理机制，除非抛出异常，否则会增加零执行开销。也就是说，只有在实际抛出异常时，性能才会降低。只要例外只在特殊情况下使用，那么就没有充分理由不使用它们。