一般来说，将 C 与类结合使用是编写快速代码同时保留结构化且设计良好的项目的良好开端，但不应忽视 C++ 的全部优秀功能。通常情况下，尝试推出自己的解决方案来解决 C++ 所涵盖的问题（例如，多态性）会比开箱即用的解决方案慢，除非您可以使解决方案非常具体地针对当前的问题。
First and foremost I must admit that I'm not a games developer, even though I have developed a fully functional 3D game engine in the past.
That aside, I do have a few words about optimizations, "spoiling" languages and so on.
When developing an application — any application — the golden rule of optimizations is "don't optimize before you make it work." You need to fully support all the functionality you want in your application, and only then you should optimize it. The reasons vary; the most important one is that while you may believe something is "slow," it may not be your bottleneck. You may be spending a lot of time optimizing something that doesn't require optimization. Furthermore, optimizations often blur your code simplicity and maintainability, which may lead to bugs in the near or far future. If this piece of code didn't require optimizations, you've complicated the code for nothing.
While that is the golden rule of optimizations, there is one big exception. When you know in advance that your application will be stressed out to the max, you need to make some different choices in the beginning (in the architecture or in the design phases) and also along the way. Also, the general rule that the platforms are getting better and faster doesn't apply for games, where the competition between the developers is on the very edge of technology. Here are several points to consider:
Some lingual features may be costly. Exceptions in C++ are a good example.
Some lingual features may actually save you code and will cost little or nothing during runtime. C++ templates are a good example, though you still may wind up creating lots of code during compilation, leading to a bigger binary, and therefore lower performance, potentially.
Infrastructures (STL for example) are generic. By making a solution specific to your domain, you MAY be improving your performance. A simple example — if you have a vector that will always be 3 items long, you will definitely be better than the stl::vector implementation. However, this is not always the case. For further reading, see chapter 11 of "Efficient C++" by Dov Bulka. This is an excellent book in general for your question.
In general, using C with classes is a good start for writing fast code while retaining a structured and well-designed project, but one should not neglect the whole of C++ excellent features. More often than not, trying to roll out your own solution to a problem covered by C++ (e.g., polymorphism) will be slower than the out-of-the-box solution, unless you can make the solution VERY specific to the problem at hand.
有一种特殊的语言功能从未在任何性能关键的引擎部件中使用 - 异常处理。这是因为在最重要的游戏开发平台（Visual Studio x86/x64）上，异常的成本相当高，即使没有发生异常，你也要付出一些成本。在某些开发控制台平台甚至不提供例外情况，或者已知支持不完整、不可靠且基本上“损坏”的情况下，可以避免例外情况。
习惯 C
除此之外，游戏程序员经常使用 C 而不是 C++，只是因为他们习惯了。
C++ without STL
As I have seen it in my professional history, what is mostly used in game development is not C with classes, but rather C++ without STL. Some parts of STL are considered too slow for a reasonable game engine performance, most notably the streams. Other parts provide reasonable general performance, but the way memory allocation is handled is mostly unacceptable for games - this applies to string and vector libraries in most scenarios. Excellent extensive discussion of this can be found in EASTL white paper. Game developers frequently use boost or even implement their own alternative to part of whole of STL (see Game STL or EASTL).
No exceptions
There is one particular language feature which is never used in any performance critical engine parts - the exception handling. This is because on the most important game development platform (Visual Studio x86/x64) the exceptions are quite costly, and you pay some cost even when no exceptions are hit. The exceptions are avoided into the extent some development console platforms even do not provide them, or the support is known to be incomplete, unreliable and basically "broken".
Used to C
Other than that, it often happens that game programmers use C instead of C++ simply because they are used to it.
If you really want to be drawing graphics as fast as possible, and you start off by saying
int size = (int)strlen(name);
that looks like barking up the wrong tree.
What does get_something get? It doesn't appear to be graphical.
Optimization doesn't consist of doing the wrong thing very quickly. It's about cutting the fat and spending all the time on the important stuff. If your graphics engine wastes a significant number of cycles on string processing, it has an issue that changing languages probably won't solve.
So… write auxiliary functions as expediently, maintainably, and clearly as possible. When you need to micro-optimize the critical path, C++ still covers the low-level style.
我猜你属于第一种情况，所以我建议不要管它。如果您需要进行更改，并且没有严重的性能问题，请务必在其上提供一些 C++isms。在一般情况下，我发现很难阅读 C 风格的 C++ 程序员，他们要么：
没有时间或者不关心学习 C++ 的做事方式（从安全角度来看，这确实是不可接受的），
正在挑选他们真正需要的 C++ 部分（非常明智），
或者他们确实需要 C 的性能特征（非常罕见）。
查看代码，可能是这些情况中的任何一种。不管怎样，现在都不重要了，代码就在你手里。
If it:
Works and you're happy with it, don't touch it.
Doesn't work, change it the way you like, as long as it's fixed afterwards.
Works and it's not fast enough, make it faster (NOT without profiling first).
I'll guess that you're falling into case 1, so I'd advise to leave it alone. If you need to change things, and don't have serious performance concerns, by all means dish out some C++isms on it. In the general case I find it difficult to read C-style C++ programmers, they either:
Haven't had time or don't care to learn the C++ way to do things (which really isn't acceptable from a safety perspective),
are cherry-picking the parts of C++ they actually need (very wise),
or they honestly need the performance characteristics of C (very rare).
Looking at the code it could be any of these cases. Either way it doesn't matter now, the code is in your hands.
发布评论
评论（4）
首先，我必须承认我不是游戏开发人员，尽管我过去开发过功能齐全的 3D 游戏引擎。
除此之外，我确实有一些关于优化、“破坏”语言等的内容。
开发应用程序（任何应用程序）时，优化的黄金法则是“在发挥作用之前不要进行优化”。您需要完全支持应用程序中所需的所有功能，然后才应该对其进行优化。原因各有不同；最重要的是，虽然您可能认为某些事情“很慢”，但它可能不是您的瓶颈。您可能花费大量时间来优化不需要优化的东西。此外，优化通常会模糊代码的简单性和可维护性，这可能会导致在不久或遥远的将来出现错误。如果这段代码不需要优化，那么你就白白地使代码复杂化了。
虽然这是优化的黄金法则，但有一个很大的例外。当您提前知道您的应用程序将承受最大压力时，您需要在开始时（在架构或设计阶段）以及整个过程中做出一些不同的选择。此外，平台变得越来越好、越来越快的一般规则并不适用于游戏，因为游戏开发者之间的竞争是在技术的最前沿。以下是需要考虑的几点：
一般来说，将 C 与类结合使用是编写快速代码同时保留结构化且设计良好的项目的良好开端，但不应忽视 C++ 的全部优秀功能。通常情况下，尝试推出自己的解决方案来解决 C++ 所涵盖的问题（例如，多态性）会比开箱即用的解决方案慢，除非您可以使解决方案非常具体地针对当前的问题。
First and foremost I must admit that I'm not a games developer, even though I have developed a fully functional 3D game engine in the past.
That aside, I do have a few words about optimizations, "spoiling" languages and so on.
When developing an application — any application — the golden rule of optimizations is "don't optimize before you make it work." You need to fully support all the functionality you want in your application, and only then you should optimize it. The reasons vary; the most important one is that while you may believe something is "slow," it may not be your bottleneck. You may be spending a lot of time optimizing something that doesn't require optimization. Furthermore, optimizations often blur your code simplicity and maintainability, which may lead to bugs in the near or far future. If this piece of code didn't require optimizations, you've complicated the code for nothing.
While that is the golden rule of optimizations, there is one big exception. When you know in advance that your application will be stressed out to the max, you need to make some different choices in the beginning (in the architecture or in the design phases) and also along the way. Also, the general rule that the platforms are getting better and faster doesn't apply for games, where the competition between the developers is on the very edge of technology. Here are several points to consider:
In general, using C with classes is a good start for writing fast code while retaining a structured and well-designed project, but one should not neglect the whole of C++ excellent features. More often than not, trying to roll out your own solution to a problem covered by C++ (e.g., polymorphism) will be slower than the out-of-the-box solution, unless you can make the solution VERY specific to the problem at hand.
没有STL的C++
正如我在我的职业生涯中看到的那样，游戏开发中最常用的不是带有类的C，而是没有STL的C++。 STL 的某些部分被认为对于合理的游戏引擎性能而言太慢，尤其是流。其他部分提供了合理的总体性能，但处理内存分配的方式对于游戏来说大多是不可接受的 - 这适用于大多数情况下的字符串和向量库。对此的精彩广泛讨论可以在 EASTL 中找到白皮书。游戏开发人员经常使用 boost，甚至实现自己的替代方案来替代整个 STL（请参阅游戏 STL或EASTL）。
没有例外
有一种特殊的语言功能从未在任何性能关键的引擎部件中使用 - 异常处理。这是因为在最重要的游戏开发平台（Visual Studio x86/x64）上，异常的成本相当高，即使没有发生异常，你也要付出一些成本。在某些开发控制台平台甚至不提供例外情况，或者已知支持不完整、不可靠且基本上“损坏”的情况下，可以避免例外情况。
习惯 C
除此之外，游戏程序员经常使用 C 而不是 C++，只是因为他们习惯了。
C++ without STL
As I have seen it in my professional history, what is mostly used in game development is not C with classes, but rather C++ without STL. Some parts of STL are considered too slow for a reasonable game engine performance, most notably the streams. Other parts provide reasonable general performance, but the way memory allocation is handled is mostly unacceptable for games - this applies to string and vector libraries in most scenarios. Excellent extensive discussion of this can be found in EASTL white paper. Game developers frequently use boost or even implement their own alternative to part of whole of STL (see Game STL or EASTL).
No exceptions
There is one particular language feature which is never used in any performance critical engine parts - the exception handling. This is because on the most important game development platform (Visual Studio x86/x64) the exceptions are quite costly, and you pay some cost even when no exceptions are hit. The exceptions are avoided into the extent some development console platforms even do not provide them, or the support is known to be incomplete, unreliable and basically "broken".
Used to C
Other than that, it often happens that game programmers use C instead of C++ simply because they are used to it.
如果你真的想尽可能快地绘制图形，那么你一开始就会说
这看起来像是找错了树。
get_something得到什么？它似乎不是图形化的。优化并不意味着很快就做错事。这是关于减少脂肪并将所有时间花在重要的事情上。如果您的图形引擎在字符串处理上浪费了大量的周期，则存在更改语言可能无法解决的问题。
所以……尽可能方便、可维护、清晰地编写辅助函数。当你需要对关键路径进行微优化时，C++仍然涵盖了低级风格。
If you really want to be drawing graphics as fast as possible, and you start off by saying
that looks like barking up the wrong tree.
What does
get_somethingget? It doesn't appear to be graphical.Optimization doesn't consist of doing the wrong thing very quickly. It's about cutting the fat and spending all the time on the important stuff. If your graphics engine wastes a significant number of cycles on string processing, it has an issue that changing languages probably won't solve.
So… write auxiliary functions as expediently, maintainably, and clearly as possible. When you need to micro-optimize the critical path, C++ still covers the low-level style.
如果它：
我猜你属于第一种情况，所以我建议不要管它。如果您需要进行更改，并且没有严重的性能问题，请务必在其上提供一些 C++isms。在一般情况下，我发现很难阅读 C 风格的 C++ 程序员，他们要么：
查看代码，可能是这些情况中的任何一种。不管怎样，现在都不重要了，代码就在你手里。
If it:
I'll guess that you're falling into case 1, so I'd advise to leave it alone. If you need to change things, and don't have serious performance concerns, by all means dish out some C++isms on it. In the general case I find it difficult to read C-style C++ programmers, they either:
Looking at the code it could be any of these cases. Either way it doesn't matter now, the code is in your hands.