C все еще широко используется в игровых движках?
Название немного неправильное, что я имею в виду на самом деле "C с классы ".
Позвольте мне объяснить, недавно я купил книгу 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, vectors и т.д ... и я широко использую библиотеки Boost; таким образом, этот стиль стал для меня неожиданностью.
Действительно ли лучше / быстрее использовать этот вид кода, чем идти в общем, оо-направлении?
Я впал в «слишком много»? абстракция "ловушка?"
Редактировать: исправлено имя метода, чтобы было понятно, что он делает.
4 ответа
Прежде всего, я должен признать, что я не разработчик игр, хотя в прошлом я разработал полнофункциональный 3D игровой движок.
Кроме того, у меня есть несколько слов об оптимизации, «испорченных» языках и так далее.
При разработке приложения — любого приложения — золотое правило оптимизации гласит: «Не оптимизируйте, пока оно не заработает». Вам нужно полностью поддерживать все функциональные возможности, которые вы хотите видеть в своем приложении, и только потом вы должны его оптимизировать. Причины различаются; самый важный из них заключается в том, что, хотя вы можете считать что-то «медленным», это может не быть вашим узким местом. Возможно, вы тратите много времени на оптимизацию того, что не требует оптимизации. Кроме того, оптимизации часто затуманивают простоту и удобство сопровождения вашего кода, что может привести к ошибкам в ближайшем или отдаленном будущем.Если этот фрагмент кода не требовал оптимизации, вы зря его усложнили.
Хотя это золотое правило оптимизации, есть одно большое исключение. Когда вы заранее знаете, что ваше приложение будет максимально загружено, вам нужно сделать несколько разных выборов в начале (на этапах архитектуры или проектирования), а также в процессе. Кроме того, общее правило о том, что платформы становятся лучше и быстрее, не распространяется на игры, где конкуренция между разработчиками находится на самом острие технологий. Вот несколько моментов, которые следует учитывать:
- Некоторые языковые особенности могут быть дорогостоящими. Хорошим примером являются исключения в C++.
- Некоторые языковые функции могут фактически сэкономить ваш код и практически ничего не стоят во время выполнения. Шаблоны C++ являются хорошим примером, хотя вы все равно можете создать много кода во время компиляции, что приведет к увеличению размера двоичного файла и, следовательно, потенциально к снижению производительности.
- Инфраструктуры (например, STL) являются общими. Создавая решение для своего домена, вы МОЖЕТЕ повысить свою производительность. Простой пример — если у вас есть вектор, который всегда будет состоять из 3 элементов, вы определенно будете лучше, чем реализация stl::vector. Тем не менее, это не всегда так. Для дальнейшего чтения см. главу 11 книги «Эффективный C++» Дова Булки. Это отличная книга в целом для вашего вопроса.
В общем, использование C с классами является хорошим началом для написания быстрого кода, сохраняя при этом структурированный и хорошо спроектированный проект, но не следует пренебрегать всеми превосходными возможностями C++.Чаще всего попытка развернуть собственное решение проблемы, охватываемой C++ (например, полиморфизм), будет медленнее, чем готовое решение, если только вы не можете сделать решение ОЧЕНЬ специфичным для конкретной проблемы. .
C++ без STL
Насколько мне известно из моей профессиональной истории, в разработке игр чаще всего используется не C с классами, а C++ без STL. Некоторые части STL считаются слишком медленными для разумной производительности игрового движка, особенно потоки. Другие части обеспечивают разумную общую производительность, но то, как обрабатывается выделение памяти, в основном неприемлемо для игр — это относится к строковым и векторным библиотекам в большинстве сценариев. Отличное подробное обсуждение этого можно найти в белой книге EASTL. Разработчики игр часто используют ускорение или даже реализуют свою собственную альтернативу части всей STL (см. Game STL или EASTL).
Никаких исключений.
Существует одна особенность языка, которая никогда не используется ни в одной из частей движка, критичных к производительности, — обработка исключений. Это связано с тем, что на самой важной платформе разработки игр (Visual Studio x86/x64) исключения обходятся довольно дорого, и вы платите определенную цену, даже если исключения не срабатывают. Исключения избегаются в той мере, в какой некоторые платформы консоли разработки даже не предоставляют их, или известно, что поддержка является неполной, ненадежной и в основном «сломанной».
Привык к C
Помимо этого, часто случается так, что разработчики игр используют C вместо C++ просто потому, что привыкли к нему.
Если вы действительно хотите рисовать графику как можно быстрее и начинаете со слов
int size = (int)strlen(name);
, это похоже на то, что вы лаете не по тому дереву.
Что получает get_something? Это не похоже на графику.
Оптимизация заключается не в том, чтобы очень быстро делать неправильные вещи. Речь идет о сокращении жира и тратить все время на важные вещи. Если ваш графический движок тратит значительное количество циклов на обработку строк, у него есть проблема, которую изменение языка, вероятно, не решит.
Итак… пишите вспомогательные функции как можно целесообразнее, удобнее и понятнее. Когда вам нужно микрооптимизировать критический путь, C++ по-прежнему поддерживает низкоуровневый стиль.
Если это:
- Работает и вас это устраивает, не трогайте его.
- Не работает, измените как хотите, лишь бы потом это исправили.
- Работает, но недостаточно быстро, увеличьте скорость (НЕ без предварительного профилирования).
Я предполагаю, что вы попадаете в случай 1, так что советую оставить его в покое. Если вам нужно что-то изменить и у вас нет серьезных проблем с производительностью, во что бы то ни стало выложите на нем несколько C++измов. В общем случае мне трудно читать программистов C++ в стиле C, они либо:
- не имеют времени или не хотят изучать способ работы на C++ (что действительно неприемлемо с точки зрения безопасности). точки зрения),
- выбирают те части C++, которые им действительно нужны (очень мудро),
- или им действительно нужны характеристики производительности C (очень редко).
Глядя на код, это может быть любой из этих случаев. В любом случае сейчас это не имеет значения, код в ваших руках.