Практично ли отказываться от STL в разработке на C ++? [закрыто]

Я знаю, что в некоторых областях (например, в игровой индустрии) STL не рекомендуется. Итак, мой вопрос: действительно ли хорошая практика не использовать STL в некоторых случаях? Если да, то каковы основные причины неиспользования STL современного C ++?

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

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

  STL обычно быстрее во время выполнения, чем либо решения в стиле C с указателями обратного вызова, либо решения на основе полиморфизма с виртуальными методами ( см. Также эту заметку Бьярна Страуструпа ). Однако, когда разработчик не понимает заданные спецификации сложности и неправильно использует библиотеку, создавая что-то вроде вектора векторов некоторых сложных объектов (хотя в C ++ 11 это уже не проблема!), Это вызывает проблемы с производительностью и защищает себя. с «вы видите, векторы довольно медленные», это может вызвать ощущение, что стандартная библиотека медленная. И как только менеджеры получают такое восприятие, они могут очень долго жить в организации.

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

  Большая часть стандартной библиотеки раньше не поддерживалась Microsoft в начале WinCE (IIRC iostreams вышел только с Visual Studio 2005), но вместо этого было возможно использовать STLport задолго до этого. И вы обычно можете получить это, чтобы скомпилировать что-нибудь. Поэтому я бы назвал эту причину недействительной.

  Кроме того, довольно долго это не "STL", а стандартная библиотека ANSI C ++. Это определяется тем же стандартным документом, который определяет сам язык. Все, что не поддерживает это, на самом деле не заслуживает того, чтобы называться C ++.

Я использую STL и Boost уже много лет. Если бы я хотел отказаться от него и использовать свои собственные инструменты, мотивация была бы:

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

Есть одна веская причина не использовать стандартную библиотеку шаблонов C ++: одна из ваших целевых платформ не имеет полностью соответствующей реализации (или вообще не имеет ее реализации), и вы знаете, что она не получит ее в течение следующих лет.

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

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

Патрик упомянул причину не использовать весь STL, а именно, что ваша платформа (ы) не имеет его.

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

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

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

«Каждая успешная игра начинается с развертывания собственной реализации связанного списка».