STL для игр, да или нет? [закрыто]


144

Каждый язык программирования имеет свою стандартную библиотеку контейнеров, алгоритмов и других полезных вещей. С такими языками, как C #, Java и Python, практически невозможно использовать язык без стандартной библиотеки lib.

Тем не менее, во многих играх C ++, над которыми я работал, мы либо вообще не использовали STL, либо использовали его незначительную долю, либо использовали нашу собственную реализацию. Трудно сказать, было ли это разумным решением для наших игр, или просто было принято из-за незнания STL.

Итак ... STL хорошо подходит или нет?



1
Да, это то, что я имел в виду под «использованием нашей собственной реализации». :)
Великолепно

3
Если у вас есть возможность найти и купить Best of Game Programming Gems, сделайте это. Джеймс Боер из ArenaNet опубликовал заголовок статьи «Использование STL в программировании игр», в котором он приводит действительно хороший пример использования STL.
chiguire

На самом деле использование Java без стандартного lib вполне возможно, оно называется J2ME: p
Барт ван Хейкелом,

1
Отличный вопрос!
Алан

Ответы:


191

Когда я работал над профессиональной разработкой игр, STL был слишком незрелым и раздутым. Но это было> 10 лет назад.

Сейчас я работаю в военной симуляции, которая предъявляет еще более жесткие требования к производительности (например, частота кадров не может быть ниже некоторого FPS). В военном симуляции STL используется повсеместно.

Некоторые из людей, которые говорят вам не использовать STL, используют аргумент, что это не всегда идеальное или даже лучшее решение проблемы. Но это не ответ на вопрос. Вопрос должен быть: есть ли что-то не так с использованием STL в играх? Я бы сказал, нет, STL в большинстве случаев является лучшей реализацией, чем то, что пользователь придумал бы самостоятельно.

Просто убедитесь, что вы знаете, как использовать STL, и используйте его в своей игре. Прочитайте несколько книг и посмотрите на код реализации в STL, который вы используете.


49
Это довольно твердый совет. Мем "STL медленный" не был правдой по крайней мере пять лет и, вероятно, намного дольше. Он будет продолжать жить, очень как «Java медленный» и «.NET медленно» нонсенс, пока не станет очевидным для всех , что это уже не так. STL помогает вам писать лучшие программы; Я бы зашел так далеко, что сказал, что неиспользование его в большинстве случаев (кроме тех 0,1% где-либо) является безответственным. (Утверждения о том, что он не соответствует данной проблемной области, часто являются скорее обвинением в
решении

5
@ Эд Роппл: Я думаю, что проблема не в том, что STL не подходит для данной проблемы, проблема в том, что он подходит для слишком большого количества проблем, что делает код в нем слишком сложным. Страшно, как люди чрезмерно используют STL, и я думаю, что это одна из причин, по которой многие (в том числе и я) вообще отказываются от его использования. Как и в одном примере, который я видел недавно, где вопрос состоял в том, как получить наибольшее из трех чисел, один из ответов заключался в том, чтобы поместить их в std :: vector, а затем в std: sort. Это определенно вынуждает решение, которое является ненужным, к очень простой проблеме.
Саймон

22
@Simon: при всем уважении, последний пример является признаком крайней невежественности и не имеет ничего общего с STL ... этот человек будет делать то же самое на любом другом языке со списками, которые можно сортировать. Это его мышление сломано.
ggambett

@EdRopple попробуйте реализовать синтаксический анализатор STL для файлов изображений PPM (всего менее 100 строк кода, если он предназначен только для P6 или P3). Половина полученного кода предназначена только для пропуска строк комментариев, потому что STL не предоставляет ничего похожегоif(stream.nextCharacter() == '#') stream.skipLine();
GameDeveloper

@DarioOO Я не знаю этот формат файла, но для этого нужны потоковые адаптеры и фильтры. Я написал этот комментарий пять лет назад, ум (и он иногда возвращается!), Но в эти дни я пишу обо всем, что не супер, супер критически важно в функциональном, основанном на преобразовании стиле и проблемах, подобных той, которую вы описываешь выпадение проблемы. Я действительно не волнует все , что многое о подсчете линии (и ИМО и не должна вас), я забочусь о правильности реализации, то ясность, то производительность, а затем такие вещи , как длина кода.
Эд Роппл

63

Я бы сказал, что, если исходить из моей головы, лучше использовать STL, если вы точно не знаете , почему вы не хотите его использовать.

Вот что такое STL: он разработан людьми, которые умнее вас. Это не должно быть оскорбительно или что-то в этом роде, просто STL разрабатывается людьми, чья работа на самом деле строит STL. Он будет практически настолько быстрым, насколько может позволить платформа, и, как правило, будет гораздо более надежным, чем домашнее решение (и это должно вызывать столько же беспокойства, если не больше, чем беспокойство о сырой скорости - потому что ваша игра нуждается Надежность чуть больше, чем вам нужна скорость, последнее бессмысленно без первого).

Жалобы на то, что STL навязывает «узкий взгляд на мир», кажутся мне немного глупыми. Они контейнеры. Они имеют ограниченный набор операций, потому что контейнеры имеют ограниченный набор операций. Что вы делаете, что не вяжется с этим?


4
Я не думаю, что кому-то нужно объяснять, почему они не должны использовать STL. Также не соглашайтесь со всем «используйте его, потому что они умнее вас». STL был разработан вокруг конкретного представления проблемной области, а не только контейнеров, то есть алгоритмов, распределителей, итераторов, признаков и т. Д. Это достаточно справедливо, но это не единственный способ взглянуть на эту проблемную область
zebrabox

2
Таким образом, вы предпочитаете домашний код, а не проверенный, надежный код? Проблемная область не сильно отличается от проекта к проекту (кроме, может быть, встроенных проектов - даже приставки имеют приличную реализацию STL!). Независимо от игры, ваша проблема не так уж отличается, и если вы делаете что-то, что намереваетесь отправить, у вас есть неявная ответственность за написание надежного кода. Может ли переопределение колеса привести к большей прочности и гибкости? Я склоняюсь к "нет". То, что это не «единственный путь», не означает, что он вообще не лучше.
Эд Роппл

20
Я бы сказал, что gamedev - это создание игр , но все в порядке. Если ваши предположения настолько плохи, что вы начинаете изучать такого рода распределение ресурсов, то да, вам нужно отступить и пересмотреть их. Но вы можете делать ослепительно быстрые приложения, которые точно так же используют STL - и, конечно, любую другую реализацию - когда вы действительно знаете, что делаете . Изучение того, что ты делаешь,> груз-кактус, отказ от STL. Никто не говорил, что STL всегда лучший ответ. Я хочу сказать, что если вы не можете понять, почему это не лучший курс , вам следует использовать STL.
Эд Роппл

11
Я не думаю, что это вообще провокационно - это сформулировано так, чтобы заставить его запоминать чью-то память, но это крайне консервативная и прямолинейная позиция. Вкратце: люди, которые разрабатывают STL, более осведомлены и лучше оснащены, чем те, кто считает, что им нужно задать этот вопрос. Если вам нужно спросить кого-то другого, подходит ли STL или нет, вам почти наверняка не хватает знаний по конкретным областям для адекватной подготовки собственного решения.
Эд Роппл

4
«Это будет практически так же быстро, как может позволить платформа». Это категорическая неправда, так как многие поставщики компиляторов не могут потрудиться переписать STL, чтобы он действительно выжал наибольшую производительность из конкретной архитектуры. STL не имеет никаких гарантий относительно характеристик производительности, за исключением больших значений O. Однако он может быть настолько же эффективным или неэффективным, насколько этого хочет производитель компилятора.
Кай

35

Я видел очень мало причин, чтобы не использовать STL для игр.

Из-за проблем с выделением памяти многие люди не знают этого, но вы можете написать собственные распределители для ваших классов контейнеров STL. Распределители - это, в основном, классы политик, которые вы передаете в свои шаблоны, чтобы определить, как выполняется распределение. Используя их, вы можете обойти любые проблемы с памятью на вашей платформе.

Конечно, если вы используете STL и делаете глупые вещи, такие как сопоставление строк с большими типами без указателей, то у вас больше проблем.


на самом деле использование больших типов не указателей в карте является хорошим примером использования, поскольку для карт stdlib требуется не делать недействительными итераторы, что вынуждает реализацию использовать указатели и индивидуально распределенные отображаемые элементы. Лучшее решение для игр - использовать google::sparse_mapили писать свое.
v.oddou

почему не плотная карта?
GameDeveloper

23

Стандартный STL имеет множество проблем, которые затрудняют его использование с играми, особенно когда речь идет о выравнивании памяти.

Индивидуальный вариант, такой как EA STL , специально разработан для игр и может значительно улучшить производительность памяти и удобство использования консоли. Он стал открытым исходным кодом в 2016 году, согласно предложению BSD-3, с репозиторием на GitHub .


19
Проблемы с использованием памяти STL и играми обычно могут быть решены с помощью пользовательских классов-распределителей. Действительно, на моей предыдущей работе наш «пользовательский» векторный класс представлял собой просто тонкую оболочку std::vector, перекрывающую распределитель по умолчанию.
Блэр Холлоуэй

1
@Blair Holloway: «Пользовательские распределители основаны на классах, а не на экземплярах. Распределители необходимы для создания и уничтожения объектов, а также для их выделения. Это вызывает смешивание двух отдельных концепций: распределение и построение. Это лишь некоторые из проблемы с stl-allocators, к сожалению. " EA STL выделяет еще несколько веских причин, по которым распределители STD плохие. Дело не только в том, могут ли они быть переопределены или нет.
Саймон

@ Симон - я не буду спорить, что система распределителей STL идеальна, потому что это не так. Нам потребовалось много времени, чтобы найти решение, которое работает. То , что я хочу сказать, что в некоторых случаях это возможно , чтобы получить работоспособную, игры-дружественное решения с использованием STL и немного работы с пользовательскими распределителями.
Блэр Холлоуэй

@Simon - для уточнения: хотя STL может быть громоздким, это очень хорошо проверенный и не содержащий ошибок фрагмент кода; если вы можете использовать его, вы сэкономите трудозатраты на отладку нестандартного решения. Моя нынешняя работа заключается в отказе от STL в пользу самодельных распределителей, и мне пришлось потратить время на отладку и рефакторинг некоторых из этого кода, потому что он не на том же уровне зрелости, что и STL.
Блэр Холлоуэй

1
@Simon: Я немного опоздал на вечеринку, но мне любопытно, если бы вы привели конкретный пример того, что вы подразумеваете под этим. Что является хорошим примером решения конкретной проблемы таким образом, что STL является слишком общим для эффективного решения?
BRaffle

21

Вот что Майк Актон (директор двигателя на Insomniac игр Spyro Дракона, Ratchet & Clank и Resistance славы) должен был сказать об этом , когда его спросили здесь . Обратите внимание, что его спросили о STL и Boost в целом, связанных с использованием в игровой разработке.

STL / Boost, это относится к gamedev? Если только его части, какие?

Вы спрашиваете о двух разных вещах здесь, верно? STL и Boost, отдельно. Но на самом деле мой ответ тот же: в этом нет ничего плохого , но я не одобряю их использование. Использование либо побуждает людей подходить к решению проблемы , а не найти решение проблемы. Решение всегда должно соответствовать имеющимся данным и ограничениям оборудования и т. Д. И STL, и Boost имеют чрезвычайно узкое представление о «мире», и их надлежащее использование ограничено. На самом деле, я не одобряю их, потому что они сразу же ведут программистов в неправильном направлении, я часто говорю, что если вам кажется, что вам нужен любой из них, вы, вероятно, не совсем понимаете проблему, с которой сталкиваетесь ».

Я также заметил, что большинство профессиональных разработчиков игр больше стремятся к C, чем к C ++.


18
Я не согласен с тем, что больше стремлюсь к C. Подавляющее большинство разработчиков игр и разработчиков SDK используют C ++. Фактически, последним основным пользователем C был id, и даже Кармак перешел на C ++ ...
Гоз

82
Комментарий мистера Актона кажется отрывочным. Вообще говоря, STL хорошо подходит для этих проблем. Если вы пытаетесь сделать что-то таким образом, чтобы подход STL казался «неправильным», вероятно, это действительно хорошая идея, чтобы переоценить свой подход и посмотреть, действительно ли вы делаете это умным способом. По моему опыту, чаще всего нет. (IMO, гораздо умнее решить проблему, хорошо понимая ее в контексте ваших инструментов, чем выбрасывать свои инструменты просто для того, чтобы переделать ее с нуля.)
Эд Роппл

50
Мой опыт работы с STL был почти противоположным. Это эффективно и экономит время. Если вы чувствуете необходимость свернуть собственную библиотеку шаблонов или контейнерную библиотеку, тогда это нормально. Но не делайте вид, что STL (или повышение, в этом отношении) плохо. Я широко использовал STL в коммерческих играх для iPhone, Nintendo DS, Wii, ПК, Mac и Xbox. Каждый раз, когда я был вынужден использовать чужую «лучшую» библиотеку, я обнаруживал, что ее не хватает и она глючит.
BRaffle

5
На DS он работает так же хорошо, как и на любой другой платформе, на которой я его использовал. Я использовал STL по всему UI и коду AI. Игра была ds.ign.com/articles/832/832147p1.html . Я работал в небольшой студии, которая была частью Amaze, которая была частью Foundation 9.
BRaffle

7
Майк все о данных. Глядя на данные предлагает лучший метод для преобразования данных. Примените это в большом масштабе, и у вас есть программирование. В этом контексте его критика имеет большой смысл. STL (и шаблоны проектирования) предполагают, что вместо того, чтобы исследовать данные, чтобы найти решение, мы исследуем решения в нашем пакете трюков, чтобы найти решение, которое работает с данными. Я не хочу говорить за Майка, но я полагаю, что он предположил бы, что такой подход к проблеме является обратным и потенциально может привести к неэффективным или раздутым решениям.
Дэн Олсон

19

Если по какой-либо причине вы переписываете что-то, что уже существует в STL, остановитесь . Используйте STL.

STL был оптимизирован за годы анализа и времени, и вполне вероятно, что вы не собираетесь писать что-то более эффективное. Это не значит, что вы должны использовать STL там, где возможно более простое решение (т.е. использовать массив, когда у вас есть известное количество вещей, а не stl :: list), но если вы пишете свою собственную реализацию карты ( базовая структура данных, а не карта игрового мира), вы делаете это неправильно.


7
map <> - это почти никогда не то, что вы хотите использовать для работы с памятью или процессором в контексте игры. hash_map <> - почти всегда лучший выбор, хотя производительность hash_map сильно отличается от поставщика. Если вы создаете игру, предназначенную либо для консоли, либо с функциями масштабируемой сетевой игры, STL может быть слишком медленным или раздутым для ваших целей.
Бен Цейглер

3
unordered_map <> теперь широко доступен и имеет чрезвычайно строгие требования к производительности в текущем проекте TR1. (В смысле чрезмерного уточнения я думаю - он даже запрещает открытое хеширование, и хотя это обычно медленнее, я не думаю, что это должно быть прямо запрещено стандартом.)

5
STL предлагает алгоритмы, а также контейнеры. Нет никаких причин не использовать stl-версию алгоритма. Например, std::sortобычно использует интросорт снизу, невероятно быстро и достаточно сложно, так что вам не захочется делать это самостоятельно.
deft_code

По правде говоря, unordered_mapC ++ 11 или boost слишком медленные, вам нужна карта хэша с открытым адресом, такая как google :: sparse_map или ваша собственная.
v.oddou

16

STL хорошо подходит для игр? Определенно. Игры представляют собой сложную часть программного обеспечения, STL предоставляет функции, которые помогают управлять сложностью, и это хорошо.

Это хорошо подходит для вашей платформы? Не обязательно. Если вы пишете для консоли, вы должны быть очень осторожны с использованием памяти и кеша. STL не делает это очень легко.

Я думаю, что слишком часто мы ошибочно принимаем «игры» за «высокопроизводительные игры в реальном времени, которые работают на встроенном или сделанном на заказ оборудовании», но важно проводить различие. Если вы пишете игру для Windows, которая не пытается работать в полноэкранном режиме с постоянной скоростью 60 кадров в секунду, то нет причин избегать инструментов, которые предоставляет вам стандартная библиотека.


10

Я знаю, что это очень поздно для вечеринки, но время меняется и ответы остаются. C ++ 11 имеет довольно широкие изменения, многие из которых должны повысить производительность C ++ и стандартной библиотеки. Похоже, что те, кто не использует STL или Boost, также не стремятся идти в ногу с новыми стандартами, в результате чего решения для домашнего прядения не нуждаются в важных улучшениях, конечно, это не всегда так.

Я использовал STL в каждом проекте с середины 90-х годов до сегодняшнего дня, за исключением короткого времени в EA. Я думаю, что анти-STL сторона имела несколько незначительных рациональных причин не использовать ее. Те в значительной степени ушли. Пользовательские распределители - это одно решение, использование резерва - другое, а не передача значения по значению - третье, но это довольно просто, и любой программист должен знать это. Более важно, хотя это использование алгоритмов. Авторы компиляторов точно знают, что делает for_each (), и могут оптимизировать код. Это не может произойти с домашним циклом. for_each () для объекта const еще лучше. Microsoft оптимизирует for_each во многих отношениях, включая сериализацию. У них также есть библиотека AMP, которая имеет parallel_for_each (). Если у вас есть шанс, поговорите с инженерами по компиляции об этом. Консольные компиляторы собираются оптимизировать то, что используется, так что Это проблема курицы и яйца. Microsoft идет очень тяжело с C ++ 11, и следующий XBox не будет отличаться. Я понятия не имею о PS4, мы еще не получили.

Пользовательские распределители - это один из способов решения проблемы с памятью, но другой (часто упускаемый из виду) вариант заключается в использовании новых и удаления на основе классов. Таким образом можно добиться значительного увеличения производительности.

Понятие, что Boost и STL имеют узкое представление о решении проблем, является чистым безумием. Я ошеломлен тем, как много вещей в STL и Boost можно настроить с помощью свойств и политик. Ищите сравнение строк без учета регистра в качестве примера.

Что касается продолжительного времени ссылок и раздувания кода, новый шаблон extern должен помочь в этом. Как правило, я нахожу, что длительное время компиляции происходит из-за избыточной связи и неправильного использования pch.

Самая веская причина для использования STL вместо homespun - миллионы людей, которые могут помочь вам с STL. Как всегда, не оптимизируйте преждевременно и тестируйте, тестируйте, тестируйте.


интересные идеи; что вы подразумеваете под " использовать новые классы на основе и удалить "? Вы имеете в виду, ускорить процесс, используя объекты уже в куче?
Джонбейкерс

9

Это горячая тема в разработке игр. Я лично не рекомендую это, кроме, возможно, для EASTL, как упомянуто выше. У меня есть две основные проблемы с STL (технически «Стандартная библиотека C ++», так как STL больше не называется) в играх. 1) При использовании STL динамическое распределение памяти часто тратит много времени в играх. 2) Использование STL поощряет подход к архитектуре игры с использованием массива структур, в то время как подход с использованием структуры массивов является гораздо более дружественным к кешу.


Как уже упоминалось в другом месте, вы можете предоставить пользовательские распределители для контейнерных классов - они могут использовать списки свободного доступа, если хотите (предварительно выделенные массивы). Массив структур против структур массивов очень зависит от того, что вы пытаетесь сделать - не существует жесткого и быстрого правила о том, какой из них лучше.
Skizz

Я ценю вашу точку зрения, что важно хорошо понимать проблему, которую вы решаете. Но с уважением, я все еще думаю, что я не согласен с вашим выводом. Каждая проблема имеет шаблоны использования, которые не могут быть выражены пользовательским распределителям STL, но могут быть легко использованы в пользовательском контейнере, таком как распределитель фиксированных блоков, реализованный с помощью плоского массива. А применение фиксированного преобразования к массиву однородных типов, скорее всего, приведет к гораздо большей когерентности кэша, чем итерация по вектору полиморфных типов и вызов виртуальных методов.
Терренс Коэн

5

По-разному. Насколько велик проект, какая платформа (ы) и каковы сроки?

Если вы работаете над большим проектом, на платформах с ограниченными ресурсами, со значительными временными рамками и бюджетом, то вы можете избежать многих проблем, избегая неизбежного ада, который будет искать полмиллиона строк кода, усеян STL, не может поддерживать частоту кадров выше 30, съедает достаточно оперативной памяти, чтобы вместить еще несколько ресурсов, и на сборку уходит 2 часа.

Однако в других ситуациях STL и даже Boost могут быть очень полезны при правильном применении. Я работал над названиями, которые использовали набор STL / Boost и были абсолютной мечтой для кодирования: меньше ошибок / утечек и простой в обслуживании код означает больше времени для написания новых интересных функций! Особенно для хобби, это большая победа в отделе мотивации.

Знайте, когда торговать производительности для удобства!


1
«Знайте, когда нужно торговать для удобства». Да. Одно только это предложение - такой же хороший ответ, как и любой другой. Выясните, чего вам нужно достичь в своей игре, проконсультируйтесь с коллегами и решите, поможет ли вам STL туда или вам помешает. Я бы сказал, что если вы не хотите устанавливать планку графики и производительности нового поколения в своей игре, STL, вероятно, поможет вам.
gkimsey

4

ИМХО, я бы сказал, что это хорошо подходит, так как STL уже хорошо работает и оптимизирован для задач, для которых он создан. Кроме того, вы работаете над игрой, поэтому используйте инструменты, которые есть у вас под рукой, что делает вашу жизнь проще и ваш код менее подвержен ошибкам.

Зачем изобретать велосипед, если вы можете работать над чем-то другим, например, над ИИ игры, пользовательским интерфейсом или еще лучше; тестирование и отладка?


2
На практике к концу проекта производительность, как правило, является критической проблемой. Если вы используете STL, у вас очень мало возможностей для оптимизации, потому что она берет ваши конкретные приложения и решает их в общем виде. Решение конкретных случаев особым образом (и без динамического выделения памяти) почти всегда обеспечивает более высокую производительность.
Терренс Коэн

2
Но если вы не хотите динамического выделения памяти, вам не следует использовать STL. Это своего рода точка. Ваш собственный код будет не лучше, и, конечно, может быть и хуже. Дизайнерское решение злоупотребить STL является проблемой здесь, не СТЛ, его возможности, или его Perf характеристики. Вы нападаете не на ту часть проблемы.
Эд Роппл

4

STL отлично подходит для использования в играх, если вы хорошо это понимаете. Наш движок довольно широко его использует, и это никогда не было проблемой. У меня нет опыта разработки консоли, что может быть совсем другой историей, но она хорошо поддерживается на всех платформах ПК (Windows / Mac / Linux).

Самое главное, чтобы понять, в чем сильные и слабые стороны каждого типа контейнера, и выбрать правильный контейнер для работы, которую вы делаете.


4

Мой бывший работодатель перешел от использования надежного набора пользовательских контейнерных классов к STL. Время сборки возросло, а простота отладки снизилась, и это довольно значительно. Если бы мы начинали с нуля, STL (возможно, лучше использованный), скорее всего, имел бы смысл, но мне никогда не было ясно, что мы получили что-то такое, переключаясь на STL, что оправдывало бы выброс работающего, быстрого, отлаживаемого кода.

Для моих личных проектов, подходит ли STL или нет, зависит от проекта. Если я попытаюсь выполнить работу, оптимизированную для работы с данными и памятью и кешем, в стиле Майка Актона, я, по крайней мере, подумаю о развертывании своих собственных структур данных. Если я создаю прототипы некоторых алгоритмов или геймплея и не заботюсь о производительности, масштабируемости, целевой платформе и т. Д., Я автоматически получу STL.


4

Мои 2 цента на это то, что STL работает просто отлично. Я разрабатывал игровой движок 3D (не качества ААА, но достаточно продвинутый - скриптовые типы объектов, отложенный рендер, интегрированная физика Bullet) для ПК, и я пока не видел, чтобы контейнеры стали главным узким местом. Неправильное использование 3D API и плохие алгоритмы были лучшими целями (определяемыми профилированием!) Каждый раз, когда я заходил и пытался добиться чуть большей производительности.



3

Хороший вопрос! Более конкретный вопрос - каковы некоторые общие требования к игре, которые не могут быть выполнены с помощью STL и Boost.

По моему опыту, жесткие ограничения памяти консольного оборудования делают любой тип контейнера динамического размера плохой идеей, независимо от того, насколько умен ваш пользовательский распределитель. Контейнеры, которые не имеют преднамеренных границ, побуждают программистов писать код, который не ограничивает границы их наборов данных. В зависимости от множества переменных, которые сложно отследить, вы можете превысить ограничения памяти. У меня есть догадка, что это одна из основных причин нестабильности в современных играх.

Кроме того, чрезмерное использование шаблонов может привести к очень длительному времени компиляции в большой кодовой базе и увеличит размер вашего исполняемого файла, чтобы он больше не помещался в кэш, скажем, вспомогательного ядра на PS3.

Тем не менее, для разработки только на ПК, я думаю, STL и Boost очень хороши. Хотя общие решения не всегда идеальны, они часто достаточно хороши. Ваше первое решение проблемы почти никогда не бывает идеальным, и вы исправляете или заменяете недостатки, пока они не станут достаточно хорошими.


2

STL подходит для вашей игры, если STL подходит для вашей игры.

Как и во всех технологических решениях, сделанных во время разработки, вам необходимо взвесить все за и против - даст ли моя собственная библиотека более выгодное использование памяти, производительность и производительность, чем простое использование STL? Возможно; хотя так же легко создать vectorреализацию, которая использует больше памяти, медленнее и требует большого объема обслуживания, чтобы оставаться функционирующей по сравнению с тем, что уже существует.

Люди не должны избегать использования STL в своих играх, потому что другие люди избегают использовать STL в играх; им следует избегать его использования, если они взвесили все свои варианты и искренне верят, что другая реализация улучшит качество их продукта.


2
Я согласен на 100% с последней частью вашего комментария, но я бы пошел еще дальше: если вы можете убедительно продемонстрировать, почему STL не является хорошим вариантом, не используйте STL. Иначе делай. Культ груза (от «о, разработчики игр используют C ++!» До «о, разработчики игр не используют STL!») Вреден для здоровья. Я бы, однако, взял немного проблемы с вашим вторым параграфом: очень маловероятно, что люди, которые все еще достаточно наивны, чтобы думать, что переопределение STL - хорошая идея, создадут лучшее, vectorчем люди STL. К тому времени, когда вы можете это сделать, вы больше не думаете, что вам нужно! :-)
Эд Роппл

2

Как и в большинстве вопросов, ответ никогда не бывает «да или нет», черный или белый. STL хорошо подходит для решения некоторых проблем, его следует использовать для этих задач. Ошибочно полагать, что это бесполезно, но также ошибочно полагать, что его целесообразно использовать в любой ситуации.

Самая большая проблема, на которую стоит обратить внимание при использовании STL в разработке игр, - это распределение памяти. Распределители STL по умолчанию, кажется, не вписываются в предпочтительные стратегии распределения для разработки игр. Конечно, можно использовать пользовательские распределители, но это делает всю идею менее привлекательной, если вы решаете, добавлять ли STL в кодовую базу без STL.

Добавьте к этому, что если ваша кодовая база не-STL, у вас может не быть достаточно знакомых с STL или концепциями шаблонов для правильной реализации пользовательских распределителей.


2

Я думаю, что это обсуждение можно резюмировать следующим образом:

посредственно написанный код, специфичный для приложения <хорошо написанный код общего назначения <хорошо написанный код для приложения

Любой, чье собственное решение попадет в категорию 3, наверняка знает ответ на первоначальный вопрос для своей конкретной проблемы. STL попадает в категорию 2. Поэтому для того, кому нужно задать вопрос «должен ли я использовать STL», ответ, вероятно, да.


2

STL подходит для использования на ПК, потому что его продвинутая система виртуальной памяти делает потребность в аккуратном распределении памяти менее важной (хотя нужно быть очень осторожным). На консоли, с ограниченными возможностями виртуальной памяти или с ее отсутствием и непомерными затратами на кеширование, вам, вероятно, лучше написать собственные структуры данных, которые имеют предсказуемые и / или ограниченные шаблоны распределения памяти. (И вы, конечно же, не ошибетесь, если сделаете то же самое с игровым проектом для ПК).


1

Я думаю, что этот вопрос на самом деле является большим не заданным вопросом - должен ли я использовать X в своем Y ? И единственный способ действительно ответить на этот вопрос - это попробовать самим. Для каждого человека, который говорит, что X отлично работает, вы найдете человека, который говорит, что это ужасно. И оба они правы - для своего проекта.

Самое замечательное в программном обеспечении, в отличие от большинства других дисциплин, заключается в том, что вы всегда можете изменить ситуацию позже, если обнаружите, что оно работает не так, как вам бы хотелось. Позже вы узнаете, что STL не работает на вас в этом проекте? Разорви это, положи что-то еще на это место. Не нравится, как вы разделили обязанности между вашими объектами? Рефакторинг. Не нравится, что вы использовали объекты? Замените их прямыми методами C. Не нравится, когда все хранится в структурах и методах для их манипулирования? Замените их объектами C ++.


1
Хотя вы правы, может быть огромный штраф за рефакторинг; поэтому принятие обоснованного решения заранее, а не произвольно сэкономит ваше время в долгосрочной перспективе.
Алан

1

Я говорю нету STL. Моя причина довольно проста:

  1. Вам не нужен STL для написания игр. Даже не большие.
  2. STL значительно увеличивает время компиляции.
  3. Большое время компиляции приводит к меньшему количеству итераций по вашей разработке.

Я считаю, что счетчик итераций имеет первостепенное значение, поэтому я просто держусь подальше от STL и любых других методов разработки, которые замедляют итерации (например, архитектура для этого или языки сценариев, которые необходимо компилировать).

Дорогостоящие итерации приводят к тому, что огромные команды разработчиков пытаются добиться чего-то, что происходит очень мало. Я видел это и слышал, и один из виновников, кажется, время компиляции для библиотек шаблонов.


1
Я согласен о времени компиляции. Любое значительное время компиляции удваивает количество потерянной работы; например, если компиляция длится 5 минут, вы каждый раз будете тратить 10 минут на кофе. ;)
Ipsquiggle

Хотя я вижу обе стороны этого аргумента, я должен сказать, что полностью согласен с вашим аргументом, Ричард. +1.
инженер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.