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

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

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

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

c++
137 голосов | спросил munificent 15 J000000Thursday10 2010, 01:55:24

22 ответа


182

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

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

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

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

ответил kevin42 15 J000000Thursday10 2010, 05:39:31
57

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

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

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

ответил Ed Ropple 18 J000000Sunday10 2010, 01:01:22
34

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

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

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

ответил Tetrad 15 J000000Thursday10 2010, 02:10:08
22

Вот что сказал об этом Майк Актон (директор по двигателям Insomniac Games of Spyro the Dragon, Ratchet & Clank and Resistance), когда его спросили

ответил Keyframe 15 J000000Thursday10 2010, 02:13:55
22

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

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

ответил Ben Zeigler 15 J000000Thursday10 2010, 02:00:27
19

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

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

ответил Ricket 15 J000000Thursday10 2010, 01:58:46
16

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

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

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

ответил Kylotan 27 J000000Tuesday10 2010, 17:05:08
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 настраиваются с помощью черт и политик. В качестве примера рассмотрите сравнение строк в зависимости от случая.

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

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

ответил Tavison 27 22012vEurope/Moscow11bEurope/MoscowTue, 27 Nov 2012 03:32:18 +0400 2012, 03:32:18
9

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

ответил Terrance Cohen 15 J000000Thursday10 2010, 04:45:02
5

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

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

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

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

ответил Jason Kozak 17 J000000Saturday10 2010, 04:12:59
4

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

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

ответил pctroll 15 J000000Thursday10 2010, 02:09:01
4

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

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

ответил Jason Morales 18 J000000Sunday10 2010, 16:16:56
4

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

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

ответил Tom Hudson 28 J000000Wednesday10 2010, 21:14:45
4

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

ответил Branan 31 PM000000100000001931 2010, 22:43:19
3

Я построил игры, используя STL, и мне это нравится, и, похоже, он работает хорошо.

ответил Kevin Laity 15 J000000Thursday10 2010, 01:58:50
2

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

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

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

ответил Blair Holloway 15 J000000Thursday10 2010, 05:38:05
2

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

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

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

ответил Dan Olson 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 10:53:18 +0400 2010, 10:53:18
2

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

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

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

ответил 24 FebruaryEurope/MoscowbThu, 24 Feb 2011 23:18:22 +0300000000pmThu, 24 Feb 2011 23:18:22 +030011 2011, 23:18:22
2

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

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

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

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

ответил Evan Rogers 12 AM00000010000001331 2011, 01:05:13
2

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

ответил Mustafa Ekici 24 AM00000010000003131 2012, 01:55:31
1

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

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

ответил Dennis Munsie 18 J000000Sunday10 2010, 05:48:13
1

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

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

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

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

ответил Richard Fabian 3 rdEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 03 Sep 2010 12:22:52 +0400 2010, 12:22:52

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132