Почему разработчики игр C ++ не используют библиотеку boost? [закрыто]

Поэтому, если вы потратите какое-то время на просмотр / ответ на вопросы в Stack Overflow под тегом C ++, вы быстро заметите, что почти каждый использует библиотеку boost ; некоторые даже скажут, что если вы не используете его, вы не пишете «настоящий» C ++ (я не согласен, но это не главное).

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

Почему разработчики игр вообще не используют библиотеку boost? Это проблемы производительности или памяти? Стиль? Что-то другое?

Я собирался задать это при переполнении стека, но я решил, что вопрос лучше задать здесь.

РЕДАКТИРОВАТЬ :

Я понимаю, что не могу говорить за всех игровых программистов, и я не видел все игровые проекты, поэтому я не могу сказать, что разработчики игр никогда не используют boost; это просто мой опыт.

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

Некоторые разработчики делают, некоторые разработчики не (в играх и в других местах). Это зависит от того, каковы потребности / требования этих разработчиков, и какие существующие технологии они должны использовать.

Стандартная библиотека C ++ s часто дают такое же лечение, и люди часто задаются вопросом, то же самое , вы задаетесь вопросом о нем тоже. Большинство причин похожи, например:

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

• Разработчик может работать на платформах, где поддержка компилятором передовых методов C ++, используемых Boost, не поддерживается должным образом, так что код Boost не компилируется вообще или работает довольно плохо. Это относится и к стандартной библиотеке, хотя в наши дни гораздо меньше.

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

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

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

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

Вернемся к этому вопросу через несколько лет.
Продолжая использовать все больше и больше библиотек Boost, я подумал, что обновлю этот вопрос, чтобы дать вескую причину того, почему вы должны использовать Boost, когда описание продукта соответствует желаемой функциональности. Это убедит даже негодяев. Скачайте openSSL, попробуйте сделать клиентское и серверное приложение с ним. Теперь попробуйте сделать это на любой платформе. Затем загрузите и используйте boost :: asio :: ssl для создания того же приложения. Если вы не уверены, что boost - это подходящее место для поиска чистого, хорошо оптимизированного, рецензируемого, кроссплатформенного кода, это простое упражнение преобразит вас.

TL; Dr версия:

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

Очень длинная версия:

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

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

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

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

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

Тем не менее , не заблуждайтесь , как только вы сможете увеличить скорость, вы получите мощное оружие для быстрого создания надежных кроссплатформенных программ. Просто возьмите boost::asioдля примера. Вы можете написать чрезвычайно мощный, масштабируемый и надежный кроссплатформенный асинхронный веб-сервер всего за пару сотен строк. На протяжении многих лет я написал несколько клиентов, серверов, прокси-серверов и т. Д., Используя всего несколько сотен строк кода, каждая из которых еще не сработала, и могу перенести их с платформы на платформу за считанные минуты.

Как уже отмечали другие, крупные компании, как правило, завязывают с унаследованными вещами или любят накатывать свои собственные, что я полностью понимаю. Также есть одна действительно глупая вещь, о которой я слышал и с которой сталкивался, когда ведущие разработки и / или руководители проектов запрещают использовать повышение, потому что оно «слишком большое». Я предполагаю, что они верят, что boost - это одна библиотека, или они никогда не слышали о BCP .

Что касается ПОЧЕМУ я решил использовать повышение

Я бы сказал, что использую его, потому что, как вы подразумеваете в своем вопросе, это «библиотека» C ++. Boost рассматривается в мире C ++ как швейцарский армейский нож вещей, которые в конечном итоге вам понадобится использовать. Таким образом, идея состоит в том, что, если есть необходимость, должна быть высокоэффективная и портативная версия в бусте. Большие компании вносят свой вклад в повышение , очень образованные люди с впечатляющим резюме вносят и поддерживают его , и когда разрабатывается новый стандарт C ++, люди обычно стремятся повысить свой уровень, чтобы увидеть, какие его части должны стать стандартом C ++ в соответствии с ISO.

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

Мы использовали немного Boost на нашем старом рабочем месте. Основными причинами, по которым в основном избегали его и ограничивали его использование, были:

• время компиляции - некоторые из них очень медленны для компиляции, и вы в конечном итоге неохотно получаете boost #include в любом из ваших заголовков
• сложность - она ​​не очень известна большинству разработчиков игр и поэтому создает нечитаемый код
• производительность - некоторые концепции работают по умолчанию медленно, например. shared_ptr

То же самое (было?) Было сказано для "более стандартного" STL. В этой статье рассказывается о EASTL, внутренней переписке (части) STL от Electronic Arts для удовлетворения потребностей разработки игр, которые значительно отличаются от потребностей «более общих» разработок приложений.

Так что, может быть, кто-то где-то переписывает (части) надстройки, чтобы учесть их потребности в разработке игр!

Кто сказал, что они не используют повышение? Я знал один или два движка C ++, которые использовали boost. Я никогда не работал с ними напрямую; но это в основном потому, что мой опыт лежит в Unreal.

Что касается причин, с которыми я столкнулся, чтобы не использовать повышение, и это субъективно:

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

Это в основном сводится к следующему: общее решение не всегда является «подходящим».

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

Я тусуюсь в StackOverflow и не использую Boost. Я добавлю свою причину, потому что она еще не упомянута.

У Boost действительно много отличных идей. Мне нравится смотреть на то, что они сделали, и пробовать новые вещи и идеи. Они великолепны, потому что это питательная среда для многих улучшений C ++.

Но повышение - очень громоздкий зверь по многим причинам. Одна из причин заключается в том, что они должны (хотят) быть совместимыми практически с любым компилятором с любыми причудами. В результате они должны использовать много уловок, таких как MPL, чтобы осуществить это. Например (давным-давно) я хотел использовать их shared_ptr, запуск его означал, что мне нужны исходники и библиотеки, которые чувствовали бы, что 90% ускорения. Я закончил писать свои собственные; 50 читаемых строк кода. (Мои требования куда строже, вроде как не слабый_тр или безопасность потоков.)

Часто вам нужно действительно небольшое подмножество ускорения, но интеграция всего ускорения просто не стоит хлопот.

Редактировать :

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

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

Но хотим ли мы портировать весь наш код? На самом деле, нет. Я предполагаю, что многие другие компании сталкиваются с той же дилеммой. Либо перепишите много проверенного и работающего кода, либо не используйте std / boost.

Я лично не использую boost или любой другой код общего назначения при создании игр, потому что игры, как правило, не имеют общего назначения. Тип кода, который вам может понадобиться для реализации игры, обычно специфичен для разработки игр, но не всегда, но в 98% случаев (случайная цифра). Вы можете использовать последние несколько бит кода из boost или какой-либо другой библиотеки, но, вероятно, лучше просто записать ту маленькую часть, которая вам нужна здесь и там.

Кстати, я думаю, что довольно забавно писать свой собственный код на c ++, поэтому я никогда не использовал boost или что-то подобное.

Наследие в домашних библиотеках не является фактором ... основная причина, по которой кому-то не следует использовать boost u другие библиотеки общего назначения, заключается в том, что они не оптимизированы по скорости и памяти, поэтому я должен упомянуть, что Cryengine использует STL, но они компилируются Это версия с открытым исходным кодом под названием STLPort, так что не бойтесь использовать STL, просто реализуйте свои собственные распределители, и все будет хорошо. Не используйте Boost Tho.