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


81

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

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

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

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

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

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

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



2
Было бы справедливо сказать, что «Boost» - это слишком большая коллекция библиотек, чтобы сделать «use boost» или «not use boost» справедливым выбором? Я полагаю, что даже Google ограничивает небольшую часть «повышения» в своих стандартах.
Дэн Олсон

Двоичные файлы игры уже достаточно массивны.
Легион

3
@Tetrad STL не буст, и STL интенсивно используется в gamedev.
rootlocus

7
Я действительно не вижу, где вопрос "не конструктивен", это нужно объяснить.
v.oddou

Ответы:


42

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

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

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

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

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

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

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

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


2
Еще один момент - некоторые компании не используют Boost из-за его негативного влияния на скорость компиляции в высокоинтерактивной среде разработки.
Стивен

27

Вернемся к этому вопросу через несколько лет.
Продолжая использовать все больше и больше библиотек 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.asio объяснит, как написать http-сервер на удивление в несколько строк, и это прекрасно, если ваша игра использует http (или любой другой ванильный TCP-протокол в этом отношении), но это становится намного сложнее, если вы хотите использовать пользовательский протокол или собственная сетевая библиотека. Мне потребовалось 20 минут, чтобы понять, как создать сервер веб-сокетов с использованием boost.asio, и несколько недель, чтобы понять, как использовать ENet ( enet.bespin.org ) через пользовательский boost.asio io_service.
ClosetGeek

21

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

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

1
повышение :: shared_ptr? как так?
Тили

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

10
(Стоит добавить, что использование make_shared может облегчить проблему.)
Kylotan

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

16

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

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


+1 за статью. Я думаю, что это прекрасно отвечает на вопрос.
egarcia

9
По моему опыту, чем более переносимой становится ваша кодовая база, тем больше вы в конечном итоге переписываете «стандартные» компоненты, такие как STL.
Яри ​​Комппа

6

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

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

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

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

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


Правда, отредактировал мой вопрос, чтобы учесть это.
Джеймс

5

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

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

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

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

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

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


1
Знаешь, есть такие инструменты, как BCP.
Бартек Банахевич

2
Вы подразумеваете, что вам не нужно поддерживать свой собственный код? Кроме того, я бы хотел, чтобы у меня была такая хорошая возможность написать все части надстройки, которые я использую, за 2 часа (что включает в себя также их тестирование по всем целям сборки, которые я собираюсь использовать, и написание тестов). Вы должны быть действительно быстрым программистом. О, а также "большинство полезных битов" в значительной степени приравнивается к "Я не могу C ++" здесь, потому что стандарт по-прежнему не хватает много .
Бартек Банахевич

2
Для начала несколько функций, предоставляемых boost, я нашел в других небольших, четко определенных пакетах, например, sigc ++. Во многих случаях более элегантно и / или более эффективно. То, что я получил в большинстве случаев, это функции, такие как потоки, умные указатели и регулярные выражения, вещи, которые сделали его стандартом. За эти годы я приобрел коллекцию сторонних библиотек и мой собственный код. «Я умею C ++» уже более 15 лет, большое спасибо.
rioki

3
@SeanFarrell ты не должен быть снисходительным. Вы говорите, что занимались C ++ в течение 15 лет, а затем в саркастичном саркастическом комментарии к Бартеку кажется, что вы не понимаете, что означает Бартек, когда он говорит «поддерживать» в сочетании с «пакетами». Поддержание не означает исправление их. Обычно это означает просто обновление до нового выпуска или сохранение версий для нескольких целей. Просто к вашему сведению.

3
Sigh Boost также работает из коробки, но все же вы упомянули о его поддержке. Я не вижу твоей логики здесь.
Бартек Банахевич

4

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

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


5
Это правда, и я не подумал об этом, но заметил, что многие люди, начинающие разработку игр на C ++, не хотят использовать boost / std. Иногда я чувствую, что ускорение обучения похоже на изучение совершенно нового языка.
Джеймс

1
@James Это в значительной степени одна из главных причин. Я опубликовал ответ, даже если вы уже приняли его, просто чтобы представить мою точку зрения как человека, который выстоял, изучив мой способ повышения, но не испытав соблазн убежать от него.

1

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

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


3
Это весело, но повышение предназначено для людей, которые хотят сделать все, вместо того, чтобы изобретать велосипед.
Бартек Банахевич

3
Это мое мнение, но ошибочно говорить, что «игры особенные». Да, автоматизация в реальном времени также особенная. Я делаю и то, и другое, и могу засвидетельствовать, что биты, где применяется повышение, очень четко очень похожи. Сказать, что они разные, - это невежество, потому что по краям они очень разные, но основное использование языка одинаково. Функция сортировки в основном одинакова, независимо от того, что вы сортируете. (Опять же, то, что вы можете, не означает, что вы этого хотите, см. Мой ответ.)
rioki

2
Вы можете добавить весь сетевой / многопользовательский уровень в свою игру, используя boost :: asio, и придумать для этого свой собственный протокол связи. Это на 100% совершенно веская причина для использования boost - любая игра, которую вы когда-либо писали, требует какой-либо сетевой функции. «Сворачивайся сам» может быть здорово, когда ты новичок и тебе нужно учиться. В этом нет ничего плохого. Но, в конце концов, я не собираюсь тратить время на то, чтобы написать свой собственный кроссплатформенный уровень асинхронной связи, когда это уже сделано и хорошо.

2
@HaywireSpark Нет необходимости оскорблять людей. Я прочитал ваш пост, и до сих пор не согласен с вами. Даже если вы говорите «обычно специфично», это совершенно не имеет значения. Почти все в boost разработано так, чтобы быть максимально переносимым и изменчивым. boost :: asio - очень общая реализация, не ориентированная на какой-либо конкретный способ сетевого взаимодействия. Я не могу представить ни одного сценария, в котором мне пришлось бы говорить: «Ну и дела, boost :: asio просто не подходит под мою модель сетевого уровня, мне лучше изобретать велосипед». Просто говорю.

2
@HaywireSpark вздохнул. Хорошего дня, приятель. Вы должны попытаться быть более открытыми для критики. Быть способным принимать критику - это часть того, чтобы быть обучаемым, и если ты не обучаем, ты никогда не научишься чему-либо. Я не придираюсь к тебе. Каждый, кто разместил ваш комментарий, не согласен с вами. Обычно это хороший признак того, что вы сказали что-то неприятное.

0

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


5
-1: По вашему убеждению, «Boost» - это «не оптимизированная скорость и память», когда существуют буквально десятки библиотек Boost, все с различной степенью скорости и эффективности использования памяти.
Николь Болас

2
... Это и есть причина, по которой многие разработчики игр избегают повышения и даже выпускают свои собственные STL, а также тот факт, что интенсивное использование шаблонов приводит к увеличению времени компиляции. Особенно имейте в виду, что отладочные сборки на MSVC требуют абсолютного минимального количества абстракций, оберток и обобщений, с которыми вы можете справиться, и все это противоречит Boost. Проблема не алгоритмическая, а просто в том, что Boost никогда не предназначался для голой скорости десятины. Никто, кроме разработчиков игр, не хотел бы компромиссов, которые в любом случае требуют.
Шон Мидлдич

2
@seanmiddleditch: я хочу сказать, что в Boost много библиотек. Некоторые из них работают быстрее и эффективнее, чем все, что вы могли бы написать для выполнения той же работы, а некоторые нет. Клеветать на весь набор библиотек для этого просто невежественно.
Николь Болас

2
Не так много разработчиков игр могут написать парсер, который работает быстрее, чем Boost.Spirit. Несмотря на то, что существует много лучших (более простых в использовании) вариантов синтаксического анализа законченных языков, Spirit очень быстро разбирает хорошо структурированные строки, даже просто преобразовывая строки в типы данных. Библиотека Boost.Xpressive также очень быстра для регулярных выражений. Имейте в виду, что многие люди, работающие над Boost, также являются людьми, работающими в комитете по стандартам C ++, и они знают, как добиться оптимальной производительности C ++ на разных платформах.
Джеральд

5
Они часто используют шаблонное метапрограммирование таким образом, чтобы большую часть работы можно было выполнять во время компиляции, а не во время выполнения, что превзойдет любую низкоуровневую оптимизацию времени выполнения, которой так гордятся разработчики игр. , Я видел увеличение производительности более чем в 50 раз при преобразовании определенных задач из некоторых распространенных высокопроизводительных библиотек C для использования эквивалентов Boost.
Джеральд
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.