Я знаю, что в некоторых областях (например, в игровой индустрии) STL не рекомендуется. Итак, мой вопрос: действительно ли хорошая практика не использовать STL в некоторых случаях? Если да, то каковы основные причины неиспользования STL современного C ++?
19
Ответы:
Я могу придумать только одну вескую причину, и она действительно редка: трудно в реальном времени. Многие вещи в стандартной библиотеке выделяют память внутренне, и это недостаточно детерминировано для жестких приложений реального времени, поэтому их следует избегать. Эти приложения, как правило, довольно просты, хотя для их разработки требуется непропорциональное время из-за очень тщательного анализа и тестирования.
Я могу вспомнить одну недопустимую, но очень распространенную причину: разработчики, которые не понимают сложности вычислений, неправильно используют STL, а затем обвиняют библиотеку.
STL обычно быстрее во время выполнения, чем либо решения в стиле C с указателями обратного вызова, либо решения на основе полиморфизма с виртуальными методами ( см. Также эту заметку Бьярна Страуструпа ). Однако, когда разработчик не понимает заданные спецификации сложности и неправильно использует библиотеку, создавая что-то вроде вектора векторов некоторых сложных объектов (хотя в C ++ 11 это уже не проблема!), Это вызывает проблемы с производительностью и защищает себя. с «вы видите, векторы довольно медленные», это может вызвать ощущение, что стандартная библиотека медленная. И как только менеджеры получают такое восприятие, они могут очень долго жить в организации.
Очевидно, что вы не можете использовать то, что не поддерживает целевая платформа. Однако в настоящее время мы нацелены на четыре наиболее распространенные мобильные платформы (Android, iOS, Bada и старый WinCE) и используем стандартную библиотеку и некоторые части Boost на всех из них.
Большая часть стандартной библиотеки раньше не поддерживалась Microsoft в начале WinCE (IIRC iostreams вышел только с Visual Studio 2005), но вместо этого было возможно использовать STLport задолго до этого. И вы обычно можете получить это, чтобы скомпилировать что-нибудь. Поэтому я бы назвал эту причину недействительной.
Кроме того, довольно долго это не "STL", а стандартная библиотека ANSI C ++. Это определяется тем же стандартным документом, который определяет сам язык. Все, что не поддерживает это, на самом деле не заслуживает того, чтобы называться C ++.
источник
sprintf
часто выделяет память тоже. На платформах реального времени стандартные функции библиотеки также имеют детерминированные ограничения. Это усложняет реализацию C ++ в реальном времени: вам нужно тщательно разработать целую стандартную библиотеку C ++, которая является более сложной работой, чем просто небольшая стандартная библиотека C.Я использую STL и Boost уже много лет. Если бы я хотел отказаться от него и использовать свои собственные инструменты, мотивация была бы:
источник
Есть одна веская причина не использовать стандартную библиотеку шаблонов C ++: одна из ваших целевых платформ не имеет полностью соответствующей реализации (или вообще не имеет ее реализации), и вы знаете, что она не получит ее в течение следующих лет.
источник
Я не знаю о сложности (эффективности реализации), но я использую контейнеры и строки Qt вместо стандартных, и они работают нормально. Я также считаю, что реализация наборов и списков в Qt проще в использовании.
Поэтому может оказаться практичным отказаться от STL, если вы можете использовать другую библиотеку, которая соответствует вашим потребностям.
источник
QList<T>::iterator
Патрик упомянул причину не использовать весь STL, а именно, что ваша платформа (ы) не имеет его.
В общем, я думаю, что вопрос не в этом. Это в основном не решение «все или ничего», а выбор за выбором. Вы можете решить использовать контейнеры и алгоритмы, но решите использовать что-то вне Std Lib для строк и ввода-вывода.
источник
Это не практично, если нет веских причин для этого. Некоторые из таких причин, о которых я могу думать, включают лишь частичную или недостаточную реализацию STL (или любой другой части стандартной библиотеки) или ограничение ресурсов (память, скорость процессора, память, ...), с помощью которых вы должны обойти прокат своих собственных инструментов, которые придерживаются того, что вам нужно сделать.
В игровой индустрии большинство (даже в некоторой степени) студий имеют свои внутренние библиотеки и реализации многих стандартных библиотечных частей, которые специально адаптированы для целевой платформы и в некоторых случаях ориентированы на engnie или даже на саму игру. Проще говоря, при разработке игры для консолей, аппаратное обеспечение очень ограничено современными стандартами. Существуют тысячи и тысячи линий ручной сборки по определенной причине. Очень важно минимизировать все виды следов ресурсов в вашем коде, чтобы игра работала быстрее, что позволяет получать больше контента в игровом мире (или, например, в большем мире), что, как мы надеемся, приведет к улучшению продукта.
«Каждая успешная игра начинается с развертывания собственной реализации связанного списка».
источник