C++ gamedev poteškoćeCitat:
No matter how powerful any game computer ever gets, it will never have any free memory or CPU cycles.
Game developers are very concerned about software performance and software development practices.
Game software often doesn't use conventional synchronous disk IO such as <stdio.h> or <fstream> but uses asynchronous IO.
Game applications cannot leak memory. If an application leaks even a small amount of memory, it eventually dies.
Every byte of allocated memory must be accounted for and trackable. This is partly to assist in leak detection but is also to enforce budgeting.
Game software rarely uses system-provided heaps but uses custom heaps instead. See Appendix item 26.
A lot of effort is expended in reducing memory fragmentation.
A lot of effort is expended in creating memory analysis tools and debugging heaps.
A lot of effort is expended in improving source and data build times.
Application code and libraries cannot be very slow in debug builds. See Appendix item 9.
Memory allocation of any type is avoided to the extent possible.
Operator new overrides (class and global) are the rule and not the exception.
Use of built-in global operator new is verboten, at least with shareable libraries.
Any memory a library allocates must be controllable by the user.
Game software must be savvy to non-default memory alignment requirements.
Memory pools are sometimes used in order to avoid fragmentation, even though they necessarily waste some memory themselves. See Appendix item 26.
Branching (if/else/while/for/do) is avoided to the extent possible, especially mispredicted branches. See Appendix item 28.
Virtual functions are avoided to the extent possible, especially in bottleneck code. See Appendix item 19.
Exception handling is usually disabled. See Appendix item 17.
RTTI is usually disabled or at least unused in shipping code.
Citat:
We also have the following practical considerations regarding C++ game programmers:
C++ isn't taught much any more in college. It's hard enough finding people who know C++, and harder finding people who understand templates of the kind you find in STL.
An increasing number of game developers are young and generic programming is foreign to them. Readers of this paper may have no trouble navigating a std STL header file, but this can be a daunting task for a less experienced programmer. An STL implementation that is very clear is worth more than experts may intially think.
Game developers (all developers, really) need to be able to examine and trace STL containers and algorithms. It's not a matter of debugging the containers themselves (which are already debugged) but a matter of debugging the user's use of the containers.
C++ templates are disliked by some because they are "tricky" and have "gotchas." You shouldn't have to be a language lawyer to use a programming language.
Odvija li se standardizacija C++a presporim tempom u odnosu na ono što tržište zahtijeva, kad se već pribjegava ovakvim rješenjima?
Čovjek stekne dojam da se izbjegavanjem iznimki, RTTI, iostreamova, STL-a i standardnog new operatora, te minimiziranjem uporabe virtualnih fja, dtora i predložaka koristi taman onaj "bolji C s klasama" podskup jezika potreban za završiti posao.
