Чи практично відмовитися від STL в розробці C ++? [зачинено]

Я знаю, що в деяких сферах (наприклад, ігрової індустрії) STL не рекомендується. Отже, моє запитання: чи справді хороша практика не використовувати STL в деяких випадках? Якщо так, то які найбільші причини не використовувати сучасний STL C ++?

• Я можу придумати лише одну дійсну причину, і це дуже рідко: важкий реальний час. Багато речей у стандартній бібліотеці виділяють пам'ять всередині, і це недостатньо детерміновано для жорстких додатків у режимі реального часу, тому їх потрібно уникати. Зазвичай ці програми досить прості, хоча для розробки потрібен непропорційний час через дуже суворий огляд та тестування.

• Я можу подумати про одну недійсну, але дуже поширену причину. Розробники, які не розуміють складності обчислювальної техніки, неправильно використовують STL і звинувачують бібліотеку.

  STL, як правило, швидше під час виконання, ніж будь-які рішення у стилі C із покажчиками зворотного виклику, або рішення, засновані на поліморфізмі, з віртуальними методами ( див. Також основну примітку цієї програми Bjarne Stroustrup ). Однак, коли розробник не розуміє заданих специфікацій складності та зловживає бібліотекою, створюючи щось на зразок векторів векторів деяких складних об'єктів (в С ++ 11, це вже не проблема!), Викликають проблеми з продуктивністю і ніж захищаються з "бачите, вектори досить повільні", це може спричинити уявлення про те, що стандартна бібліотека повільна. І як тільки менеджери отримують таке сприйняття, воно може дуже довго прожити в організації.

• Очевидно, ви не можете використовувати нічого, що платформа, на яку ви орієнтовані, не підтримує. Однак зараз ми орієнтуємось на чотири найпоширеніші мобільні платформи (Android, iOS, Bada та старі WinCE) та використовуємо стандартну бібліотеку та деякі частини Boost для всіх.

  Більшість стандартних бібліотек Microsoft раніше не підтримувалася Microsoft WinCE (іостри IIRC виходили лише з Visual Studio 2005), але STLport можна було використовувати задовго до цього. І зазвичай ви можете отримати це для компіляції до чого завгодно. Тому я б назвав цю причину також недійсною.

  Крім того, досить тривалий час це не "STL", а стандартна бібліотека ANSI C ++. Це визначається тим самим стандартним документом, який визначає саму мову. Все, що не підтримує, насправді не заслуговує на те, щоб називатися C ++.

Я використовую STL та прискорення вже багато років. Якби я хотів відмовитися від цього і використати свої власні інструменти, мотивація буде такою:

1. Скорочення часу на компіляцію (75%). Тільки включаючи iostreams, ви можете додати 1 мільйон рядків коду до вашого модуля. Так, попередньо складені заголовки дуже допомагають, але це все ще дуже уповільнює компіляцію у великих проектах. Зрештою, він витрачає багато часу на кожного, хто працює над цим.
2. Продуктивність. (25%) STL написано, щоб він працював загалом, але ви можете оптимізувати ваші структури так, як вам потрібно. Наприклад, у вас можуть бути структури даних з мільйонами коротких рядків. Можливо, набагато швидше використовувати спеціальний клас рядків на основі принципу boost :: small_vector (невеликий статичний локальний вектор даних, динамічне розподілення лише для більших рядків), такі зміни можуть зробити критичні розділи коду в багато разів швидшими.

Є одна важлива причина не використовувати стандартну бібліотеку шаблонів C ++: Одна з ваших цільових платформ не має повністю відповідає її реалізації (або її взагалі немає), і ви знаєте, що вона не отримає її протягом наступних років.

Я не знаю про складність (ефективність реалізації), але я широко використовую контейнери та рядки Qt замість std, і вони прекрасно працюють. Я також вважаю, що Qt реалізація наборів і списків простіший у використанні.

Отже, відмовитися від STL може бути практично, якщо ви можете використовувати іншу бібліотеку, яка відповідає вашим потребам.

Патрік згадав про причину не використовувати всю STL, а саме те, що на вашій платформі немає.

Взагалі я думаю, що питання не має сенсу. Це здебільшого не все або нічого, але це вибір. Ви можете вирішити використовувати контейнери та алгоритми, але вирішите використовувати щось поза Std Lib для рядків та i / o.

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

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

"Кожна успішна гра починається з розгортання власної реалізації пов'язаного списку."