Причина отказа от использования STL?
Возможный дубликат:
В STL или! STL, вот вопрос
Есть ли случаи, когда следует избегать использования С++ STL в его/ее проекте?
Ответы
Ответ 1
Если вы не можете использовать RTTI и/или исключения, вы можете столкнуться с тем, что части STL не будут работать. Это так, например. для собственных приложений для Android. Поэтому, если это не дает вам то, что вам нужно, это причина не использовать его!
Ответ 2
Когда вы решите использовать фреймворк вроде Qt, вы можете использовать списки, векторы и т.д. из Qt, а не STL. Не использовать STL в этом случае избавляет вас от необходимости конвертировать из STL в эквиваленты Qt, когда вам нужно использовать их в своем графическом интерфейсе.
Это дискуссионно, и не все хотят использовать все из Qt
из http://doc.qt.nokia.com/latest/containers.html
Эти классы контейнеров предназначены для того, чтобы быть легче, безопаснее и проще в использовании, чем контейнеры STL. Если вы не знакомы с STL или предпочитаете делать что-то "способ Qt", вы можете использовать эти классы вместо классов STL.
Ответ 3
Если вам очень понравится размер исполняемого файла, вы можете избежать использования STL в своей программе.
Например, uTorrent не использует STL, и это одна из причин, почему это так мало.
Поскольку STL много полагается на шаблоны (это стандартная библиотека TEMPLATE), во многих случаях вы используете шаблоны, компилятор должен генерировать дополнительный код для каждого типа, который вы используете при работе с STL.
Это полиморфизм времени компиляции и увеличит ваш исполняемый размер, чем больше вы его используете.
Если вы исключаете STL из своего проекта (и используете шаблоны экономно или вообще не используете), размер вашего кода будет меньше. Обратите внимание, что это не обязательно будет быстрее.
Также обратите внимание, что я не говорю об использовании памяти программы во время выполнения, поскольку это будет зависеть от того, сколько объектов вы выделили во время вашего приложения.
Я говорю о вашем двоичном исполняемом файле.
Если вы хотите привести пример, обратите внимание, что простая программа Hello World при компиляции может быть больше, чем умный код demo, который может включать в себя весь 3D-движок (время выполнения) в очень маленьком исполняемом файле.
Информация о размере uTorrent:
Официальные часто задаваемые вопросы (с 2008 года), этот вопрос не встречается в последних часто задаваемых вопросах.
Как был запрограммирован uTorrent настолько эффективным?
Второе сообщение об этом.
Третий пост относительно этого.
Обратите внимание, что хотя uTorrent составляет > 300 кбайт и сжимается UPX, он по-прежнему очень мал, когда вы учитываете, что он способен делать.
Ответ 4
Я бы сказал, что могут быть случаи, когда вы не используете какую-либо особенность STL в своем проекте для данного обстоятельства, потому что вы можете настраивать его лучше для своих нужд. Коллекции STL носят общий характер.
Возможно, вы захотите в своем коде:
- Запрещенные контейнеры, которые являются потокобезопасными. (STL - нет).
- Строковый класс, который неизменен по своей природе и копирует фактические данные "по ссылке" (с некоторым механизмом).
- Эффективный класс построения строк, который не является ostringstream (хотя и не является частью STL, но может означать всю стандартную библиотеку)
- которые используют Map и Reduce (не путать с std:: map. Map and Reduce - это способ итерации по коллекции с использованием нескольких потоков или процессов, возможно даже распределенных на разных машинах).
Эй, смотри, столько мощностей было написано, потому что то, что предоставила стандартная библиотека в то время, действительно не отвечало потребностям программиста и, таким образом, предоставляло альтернативы.
Я не уверен, что это то, что вы имели в виду, или если вы специально подразумевали, что STL всегда должен быть "запрещен" (например, программирование драйвера устройства, где шаблоны считаются раздутыми, хотя это не всегда так).
Ответ 5
Не совсем. Нет никакого оправдания запретить использование целой библиотеки, если только эта библиотека не служит только одной функции, что не соответствует стандартной библиотеке. Предоставляемые средства должны оцениваться на основе каждой функции, например, вы можете утверждать, что вам нужен контейнер, который выполняет более конкретную цель, чем vector
, но это не повод запретить использование deque
, iostream
или for_each
.
Более того, код, созданный с помощью шаблона, не будет более раздутым, чем эквивалентный код, написанный вручную. Вы не будете сохранять раздувание кода, отказываясь использовать std::vector
, а затем записывая свой эквивалентный вектор для float и double. Особенно в 2011 году размер исполняемого файла довольно бессмыслен по сравнению с размерами других вещей, таких как медиа в огромном, подавляющем большинстве ситуаций.
Ответ 6
Если вы работаете с конкретными стандартами, которые его запрещают.
Например, рекомендации MISRA C/С++ нацелены на автомобильные и встраиваемые системы и запрещают использовать динамическое распределение памяти, поэтому вы можете выбрать избегайте контейнеров STL.
Примечание. Рекомендация MISRA - это всего лишь пример стандарта, который может повлиять на ваш выбор для использования STL. В этом конкретном руководстве не исключается использование всех STL. Но (я считаю) он исключает использование контейнеров STL, поскольку они полагаются на распределение памяти во время выполнения.
Ответ 7
Он может увеличить размер исполняемого файла. если вы работаете на встроенной платформе, вы можете исключить STL.
Ответ 8
Когда вы используете что-то вроде библиотеки Qt, которая реализует идентичные функции, вам может не понадобиться STL. Может зависеть от других потребностей, таких как производительность.
Ответ 9
Единственная причина в том, что вы работаете с встроенными системами с низкой памятью или если ваши правила кодирования проекта явно запрещают STL.
Я не могу по-другому обосновать, что вручную рулон вашей собственной несовместимой, связанной с ошибкой реализации некоторых функций в STL.
Ответ 10
TR18015 относится к некоторым ограничениям STL. Он смотрит на него под другим углом - какие компиляторы могли бы сделать лучше, но все же интересно (если в глубине) читать.
В целом я был бы осторожен с микропроцессорами и небольшими встроенными системами. Во-первых, оптимизация компилятора не соответствует тем, что вы знаете, с настольных компьютеров, и, которые вы запускаете в аппаратные ограничения намного раньше.
Сказав это, это сильно зависит от используемых вами библиотек. Потоки ввода-вывода, как известно, медленны (и требуют тщательной реализации, чтобы их не было), тогда как std::vector
является просто тонкой оболочкой.