Question

标题有点用词不当，我的意思是“C with classes”。

让我解释一下，最近我买了一本书ShaderX7，它带有一个关于阴影贴图技术的文章之一的Unigine引擎的精简（和旧）副本。

当我意识到，虽然作者使用的是C ++和继承以及所有C ++的优点，但是我正在考虑代码，大多数方法内容本质上都是C风格的代码;例如：

int Shader::get_param(const char *name,char *src,String &dest) const {
    char *s = src;
    int size = (int)strlen(name);
    while(*s) {
        if(!strncmp(s,name,size)) {
            if((s == src || strchr("\n\r",*(s - 1))) && strchr(" \t",*(s + size))) {
                src = s;
                s += size;
                dest.clear();
                while(*s && strchr(" \t",*s)) s++;
                while(*s && strchr(" \t\n\r",*s) == NULL) dest += *s++;
                if(dest.isEmpty()) {
                    Log::error("Shader::get_param(): can't get \"%s\" \n",name);
                    return 0;
                }
                memmove(src,s,strlen(s) + 1);
                return 1;
            }
        }
        s++;
    }
    return 0;
}

我并不是说这很糟糕，它完成了这项工作，而这才是最重要的，但我更习惯于C ++风格的构造，使用std :: string，vector等......我充分利用了Boost库;所以这种风格对我来说有点意外。

使用这种代码比使用通用的OO方式真的更好/更快吗？

我是否陷入了“过多的抽象”陷阱？

编辑：更正的方法名称，以明确它正在做什么。

Answer 1

首先，我必须承认我不是游戏开发者，尽管我过去已经开发了功能齐全的3D游戏引擎。

除此之外，我确实有一些关于优化，“破坏”语言等等的话。

在开发应用程序时 - 任何应用程序 - 优化的黄金法则是“在使其运行之前不要进行优化”。您需要完全支持应用程序中所需的所有功能，然后才应优化它。原因各不相同;最重要的一点是，虽然你可能认为某些事情“缓慢”，但它可能不是你的瓶颈。您可能会花费大量时间来优化不需要优化的内容。此外，优化通常会使代码简单性和可维护性变得模糊，这可能会导致近期或远期的错误。如果这段代码不需要优化，那么你就无需复制代码。

虽然这是优化的黄金法则，但有一个很大的例外。如果您事先知道您的应用程序将会受到最大压力，那么您需要在开始时（在架构或设计阶段）以及整个过程中做出一些不同的选择。此外，平台越来越好的一般规则并不适用于游戏，开发者之间的竞争处于技术的最前沿。以下几点需要考虑：

某些语言特征可能代价高昂。 C ++中的例外就是一个很好的例子。
某些语言功能实际上可能会保存您的代码，并且在运行时会花费很少或根本没有。 C ++模板是一个很好的例子，尽管你仍然可能在编译期间创建大量代码，从而导致更大的二进制文件，从而降低性能。
基础设施（例如STL）是通用的。通过制定特定于您的域的解决方案，您可以提高性能。一个简单的例子 - 如果你有一个总是3项长的向量，你肯定会比stl :: vector实现更好。然而，这并非总是如此。有关进一步阅读，请参阅Dov Bulka的“高效C ++”第11章。对于你的问题，这是一本很好的书。

通常，在保留结构化且设计良好的项目时，将C与类一起使用是编写快速代码的良好开端，但不应忽视整个C ++的优秀特性。通常，尝试为C ++所涵盖的问题（例如，多态）推出自己的解决方案将比开箱即用的解决方案慢，除非您可以使解决方案非常特定于手头的问题

Answer 2

没有STL的C ++

正如我在专业史上所看到的那样，游戏开发中最常用的不是带有类的C，而是没有STL的C ++。对于合理的游戏引擎性能，STL的某些部分被认为太慢，尤其是流。其他部分提供合理的一般性能，但处理内存分配的方式对于游戏来说大多是不可接受的 - 这适用于大多数情况下的字符串和向量库。关于这一点的广泛讨论可以在EASTL white paper中找到。游戏开发者经常使用boost或甚至实现他们自己的替代STL的部分（参见Game STL或EASTL）。

没有例外

有一种特殊的语言功能从未在任何性能关键引擎部件中使用 - 异常处理。这是因为在最重要的游戏开发平台（Visual Studio x86 / x64）上，异常是非常昂贵的，即使没有例外，你也需要付出一些代价。在一些开发控制台平台甚至不提供它们的情况下，或者已知支持是不完整的，不可靠的并且基本上“破坏”的情况下，可以避免例外。

用于C

除此之外，游戏程序员经常使用C而不是C ++，因为他们已经习惯了。

Answer 3

如果你真的想尽快绘制图形，那么首先要说

int size = (int)strlen(name);

看起来像吠叫错误的树。

get_something得到了什么？它似乎不是图形的。

优化不包括快速做错事。这是关于削减脂肪，并将所有时间花在重要的事情上。如果您的图形引擎在字符串处理上浪费了大量的周期，那么它就有一个问题，即更改语言可能无法解决。

所以...尽可能方便，可维护和清晰地编写辅助功能。当你需要微观优化关键路径时，C ++仍然涵盖了低级风格。

Answer 4

如果：

工作，你很满意，不要碰它。
不起作用，只要之后已经修好，就可以按自己喜欢的方式进行更改。
工作并且速度不够快，速度更快（不首先进行剖析）。

我猜你会陷入案例1，所以我建议不要管它。如果你需要改变一些东西，并且没有严重的性能问题，那么就一定会在它上面提出一些C ++主义。在一般情况下，我发现很难阅读C风格的C ++程序员，他们要么：

没有时间或者不关心学习C ++的做事方式（从安全角度来看这是不可接受的），
正在挑选他们实际需要的C ++部分（非常明智），
或者他们真的需要C的性能特征（非常罕见）。

查看代码可能是这些情况中的任何一种。无论哪种方式现在都没关系，代码就掌握在你的手中。

C仍在游戏引擎中广泛使用吗？

4 个答案:

没有STL的C ++

没有例外

用于C