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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я знаю, что это очень поздно для вечеринки, но время меняется и ответы остаются. 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. Как всегда, не оптимизируйте преждевременно и тестируйте, тестируйте, тестируйте.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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