Чому розробники ігор C ++ не використовують бібліотеку підсилення? [зачинено]

Тож якщо ви витратите будь-який час на перегляд / відповіді на запитання щодо переповнення стека під тегом C ++, ви швидко помітите, що майже всі користуються бібліотекою підвищення ; дехто навіть сказав, що якщо ви не користуєтесь ним, ви не пишете "справжній" C ++ (я не згоден, але це не суть).

Але є ігрова індустрія, яка добре відома тим, що використовує C ++ і не використовує прискорення. Не можу не задатися питанням, чому це так. Мені неважливо використовувати прискорення, тому що я пишу ігри (зараз) як хобі, і частина цього хобі - це реалізація того, що мені потрібно, коли я вмію і використовую нестандартні бібліотеки, коли не можу. Але це тільки я.

Чому розробники ігор взагалі не використовують бібліотеку підвищення? Це стосується продуктивності чи пам’яті? Стиль? Щось ще?

Я збирався задати це питання щодо переповнення стека, але зрозумів, що краще тут задати питання.

Редагувати:

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

Дозвольте мені відредагувати моє запитання, щоб також запитати, якщо ви використовуєте boost, чому ви вирішили його використовувати?

Деякі розробники це роблять, деякі розробники не роблять (в іграх та інших місцях). Це залежить від того, якими є потреби / вимоги цих розробників та які існуючі технології вони мають використовувати.

Стандартна бібліотека C ++ часто отримує одне і те ж лікування, і люди часто задаються питанням про те, що вам цікаво і про це . Більшість причин подібні, наприклад:

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

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

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

Я думаю, що вищезазначене - це дві розумні причини, хоча, безумовно, є й інші. Ви повинні бути обережними, тому що багато причин уникати Boost, стандартних бібліотек або будь-якого іншого, що зводиться до синдрому "не винайдене тут", що може бути свідченням того, що причина не дуже обґрунтована в практичних реаліях.

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

Зрештою, справа в тому, щоб оцінити свої вимоги та витратити час відповідно до бажаної мети та визначити, який варіант відповідає вашим потребам найкращим чином. Розробники, які не використовують Boost або стандартну бібліотеку, зазвичай робили це і дійшли такого висновку - можливо, ви теж будете, а можливо, ні.

Змінити Повернення до цього питання через кілька років
Продовжуючи використовувати все нові й нові бібліотеки, я подумав би оновити це питання, щоб навести ґрунтовний випадок, чому слід використовувати прискорення, коли опис продукту відповідає бажаному функціоналу. У цьому переконають навіть най-кажуть. Завантажте openSSL, спробуйте зробити з ним клієнтську та серверну програму. Тепер спробуйте зробити цю роботу на кожній платформі. Потім завантажте та використовуйте boost :: asio :: ssl, щоб зробити ту саму програму. Якщо ви не впевнені, що стимулювання - це правильне місце для пошуку чистого, добре оптимізованого, рецензованого, кросплатформенного коду, ця проста вправа перетворить вас.

Tl; dr версія:

На мою думку, ви не бачите тонни інді чи середніх фірм, що займаються розробкою середнього розміру, які використовують прискорення, тому що це масивний і потужний дикий звір, якого нелегко приручити, і ви в основному самостійно намагаєтеся навчитися використовувати його. Документації не вистачає кількома способами (див. Довгу версію), і "громада" навколо проекту або здається відсутнім, розсіяним або неактивним (порівняно з іншими проектами).

Дуже довга версія:

Я розумію, що вже прийнята відповідь, але як хтось, хто насправді використовує імпульс майже в кожному проекті, який я роблю, я думав, що опублікую відповідь.

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

Крім того, важко знайти будь-яке місце, де ви відчуваєте, що знайшли "спільноту" навколо проекту. Насправді громада здається неіснуючою чи кочовою. На жаль, навіть їх списком розсилки було перероблено так багато сайтів з п'явками, що ви можете спуститись із цієї кролячої нори, завжди перекидаючись туди, куди ви почали.

Ці два фактори роблять навчання використання прискорених бібліотек досить складним завданням. Навіть якщо технічні можливості використання boost не надмірно складні, це величезний набір бібліотек, і це дивиться, коли все, що ви озброєні, - це кілька фрагментів коду та розпорошені фрагменти списку розсилки з найтемніших куточків Інтернету. ... ну ви зрозуміли ідею.

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

Однак , не помиляйтесь , як тільки ви зможете досягти прискорення, ви отримали потужну зброю для швидкого створення міцних, багатоплатформних програм. Візьмемо boost::asioдля прикладу. Ви можете написати асинхронний веб-сервер надзвичайно потужного, масштабованого та непомітного крос-платформного просто за пару сотень рядків. Я написав декілька клієнтів, серверів, проксі-серверів тощо протягом багатьох років, лише кілька сотень рядків коду, які мені ще не підлягають, і можу перенести їх з платформи на платформу за лічені хвилини.

Як зазначали інші, більші компанії, як правило, застрягають зі спадщиною або люблять згортати власні, які я цілком розумію. Існує також ця справді нерозумна річ, про яку я чув і стикався, де розробники ведуть і / або керівники проектів забороняють використовувати прискорення, оскільки воно "занадто велике". Я гадаю, що вони вважають, що підвищення є однією бібліотекою або вони ніколи не чули про BCP .

Щодо ЧОМУ я вибираю використовувати boost

Я б сказав, що я його використовую, оскільки, як ви розумієте у своєму запитанні, це "бібліотека C ++". Збільшення розглядається у світі С ++ як швейцарський армійський ніж речей, які в кінцевому підсумку вам потрібно буде використовувати. Тож ідея полягає у тому, що якщо є потреба, то має бути високоефективна та портативна версія цього прискорення. Великі компанії сприяють збільшенню , дуже освічені люди з вражаючими резюме сприяють і підтримують його , і коли розробляється новий стандарт C ++, люди зазвичай намагаються підвищити рівень бачення того, які частини його повинні стати стандартизованими ISO + C ++.

Тож якщо мені потрібно додати певну функціональність, для якої, ймовірно, існує існуюча бібліотека, перше місце, на який я буду виглядати, - це підвищення лише тому, що я досить впевнений у ставці на те, що він досить добре оптимізований, портативний, він буде підтримуватися та підтримуватися для дуже довго і помилки будуть знайдені та вирішені. У світі з відкритим кодом ці якості можуть бути дуже важкими.

Ми використали трохи прискорення на старому робочому місці. Основними причинами, які здебільшого уникають та обмежують його використання, були:

• рази компіляції - деякі з них дуже повільно збирати, і ви, в кінцевому підсумку, не бажаєте мати збільшення #includes у будь-якому з своїх заголовків
• складність - це не добре відомо більшістю розробників ігор, а тому створює нечитабельний код
• продуктивність - деякі поняття виконують повільно за замовчуванням, наприклад. shared_ptr

Те ж саме (було?) Сказано для "більш стандартної" STL. Ця стаття розповідає про EASTL, внутрішню переписку (частини) STL від Electronic Arts, щоб задовольнити потреби розвитку ігор, які відрізняються від потреб «більш загальної» розробки додатків.

То, можливо, хтось десь переписує (частину) підсилення, щоб задовольнити їх потреби в розробці ігор!

Хто каже, що вони не використовують прискорення? Я знав один або два двигуни С ++, які використовували прискорення. Я ніколи безпосередньо не працював з ними; але це здебільшого тому, що мій досвід лежить у Unreal.

Що стосується причин, з якими я стикався через те, що не використовую прискорення, і вони є суб'єктивними:

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

Це в основному зводиться до: загальне рішення не завжди є "правильним пристосуванням".

Я впевнений, що хтось, хто насправді працював з бібліотекою, міг би прокоментувати краще.

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

Boost має багато чудових ідей, насправді. Мені подобається дивитися, що вони зробили, і випробовувати нові речі та ідеї. Вони чудові, тому що це поживна середовище для багатьох поліпшень C ++.

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

Часто вам потрібен дійсно невеликий набір підсилення, але інтегрувати всю сукупність прискорень просто не варто.

Редагувати :

Просто зробити це зрозуміло, оскільки, здається, воно не перейшло чітко (тобто, поворот). Я використовую чи використовувати сторонні бібліотеки. Але в більшості випадків, якщо всі рівні, інтегруючи сторонні бібліотеки або збільшити, інша стороння бібліотека швидша і чистіша. Решта робиться у вправі «2h» пальцем. Я дуже важко дивлюся на його складання або купую питання.

У нашому випадку (не в іграх) у нас є чудова причина не використовувати boost (ні std): у нас є багато коду, який датується десятиліттям. На думку людей похилого віку, std і boost були або неповними, повними помилок, або просто надто повільними для потрібних нам високопродуктивних речей. Тож деякі базові класи були реалізовані, використовуючи ті самі поняття (як ітератори) та часто оптимізовані під наші алгоритми. Нині всі три бібліотеки (наша, std та boost) дуже схожі.

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

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

Зі сторони, я вважаю, що писати свій власний код у c ++ досить цікаво, тому я ніколи не використовую прискорення чи щось подібне.

спадщина в домашніх бібліотеках не є фактором ... Основна причина, чому ніхто не повинен використовувати прискорення в іншій бібліотеці загального призначення, це тому, що вони не оптимізовані швидкість і пам'ять, тому я повинен зазначити, що Cryengine використовує STL, але вони компілюють це у відкритій версії з назвою STLPort, тому не бійтеся використовувати STL, просто реалізовуйте свої спеціальні розподільники, і ви все в порядку. не використовуйте прискорене тхо.