Для STL или! STL, это вопрос

Ответ 1

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

Вы также можете не использовать STL для конкретного случая, поскольку существуют более подходящие контейнеры, которые не находятся в текущем стандарте, такие как boost:: array или boost:: unordered_map.

Ответ 2

Основными причинами не использования STL являются следующие:

• Ваша реализация на С++ устарела и имеет ужасную поддержку шаблонов.
• Вы не можете использовать распределение динамической памяти.

Оба являются очень необычными требованиями на практике.

Для долгосрочного проекта, когда ваши собственные контейнеры, которые перекрывают функциональность с STL, просто увеличивают затраты на обслуживание и разработку.

Ответ 3

Есть только так много преимуществ использования stl. Для долгосрочного проекта выгоды перевешивают затраты.

• Новые программисты могут понять контейнеры с первого дня, что дает им больше времени для изучения другого кода в проекте. (предполагая, что они уже знают STL, как любой компетентный программист на С++)
• Исправление ошибок в контейнерах отсасывает и тратит время, которое может быть потрачено на улучшение бизнес-логики.
• Скорее всего, вы не собираетесь писать их, а STL будет реализован в любом случае.

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

Ответ 4

Обычно я считаю, что лучше всего использовать STL с пользовательскими распределителями вместо замены контейнеров STL вручную. Хорошая вещь о STL заключается в том, что вы платите только за то, что используете.

Ответ 5

Я думаю, что это типичный сценарий сборки и покупки. Тем не менее, я думаю, что в этом случае я бы почти всегда "покупал" и использовал STL - или лучшее решение (возможно, что-то от Boost), прежде чем катиться самостоятельно. Вы должны сосредоточить большую часть своих усилий на том, что делает ваше приложение, а не на строительных блоках, которые он использует.

Ответ 6

Я так не думаю. При создании моих собственных контейнеров я бы даже попытался сделать их совместимыми с STL, потому что мощь общих алгоритмов слишком велика, чтобы отказаться. STL следует хотя бы номинально использовать, даже если все, что вы делаете, это написать свой собственный контейнер и специализироваться на каждом алгоритме. Таким образом, каждый алгоритм сортировки может быть вызван sort (c.begin(), c.end()). Если вы специализируете сортировку, чтобы иметь тот же эффект, даже если она работает по-другому.

Ответ 7

Кодирование для Symbian.

STLPort поддерживает Symbian 9, поэтому случай с использованием STL слабее, чем он был ( "он недоступен" - довольно убедительный случай), но STL по-прежнему чуждо всем библиотекам Symbian, поэтому может быть больше чем просто делать что-то с Symbian.

Конечно, на этом основании можно утверждать, что кодирование для Symbian не является "проектом программирования на С++".

Ответ 8

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

Ответ 9

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

Ответ 10

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

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

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

Ответ 11

Основной проблемой, которую я видел, является интеграция с устаревшим кодом, который опирается на новый оператор без металирования.

Ответ 12

Я начал программировать C назад примерно в 1984 или около того и никогда не использовал STL. На протяжении многих лет я загрузил свои собственные библиотеки функций, и они развились и выросли, когда STL еще не стабилизировался и не нуждался в поддержке кросс-платформы. Моя общая библиотека выросла, чтобы включить код других (в основном такие вещи, как libjpeg, libpng, ffmpeg, mysql) и несколько других, и я предпочел бы свести к минимуму объем внешнего кода. Я уверен, что теперь STL замечательный, но, честно говоря, я доволен элементами в своем наборе инструментов и не вижу в этом смысла, чтобы загрузить его с помощью большего количества инструментов. Но я, конечно, вижу великие прыжки и ограничения, которые могут сделать новые программисты, используя STL, без необходимости кодировать все это с нуля.

Ответ 13

Стандартная С++ perversely позволяет реализовать некоторые операции итератора для исключения исключений. В некоторых случаях эта возможность может быть проблематичной. Таким образом, вы можете реализовать свой собственный простой контейнер, который гарантированно не будет генерировать исключения для критических операций.

Ответ 14

Введение:

STL - отличная библиотека и полезная во многих случаях, но она окончательно не решает всех ситуаций. Ответ STL или! STL подобен ответу: "Соответствует ли STL ваша потребность или нет?"

Плюсы STL

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

Контрасты STL

Не требуется, чтобы вам нужен простой график, красно-черное дерево или очень сложная база данных элементов с одновременным доступом к AI через квантовый компьютер. Дело в том, что STL этого не делает и никогда не решит все.

Следующие аспекты - это всего лишь несколько примеров, но в основном это следствие этого факта: STL - это настоящая библиотека с ограничениями.

• Исключения: реле STL на исключениях, поэтому, если по какой-либо причине вы не можете принимать исключения (например, критически важные для безопасности), вы не можете использовать STL. Правильно! исключения могут быть отключены, но это не решает дизайн ретрансляции STL на них и в конечном итоге приведет к сбою.

• Необходимость конкретной (еще не включенной) структуры данных: график, дерево и т.д.

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

• Concurrency соображения: либо вам нужно concurrency, и STL не предоставляют то, что вам нужно (например, блокировка чтения-записи не может (легко) использоваться из-за двунаправленного [] operator). Либо вы можете создать контейнер, пользующийся многопоточным доступом, для более быстрого доступа/поиска/вставки/независимо.

• STL должен соответствовать вашим потребностям, но обратное также верно: вам нужно выполнить потребности STL. Не пытайтесь использовать std::vector во встроенном микроконтроллере с 1K неуправляемой оперативной памяти.

• Совместимость с другими библиотеками. Возможно, по историческим причинам библиотеки, которые вы используете, не принимают STL (например, QtWidgets интенсивно используют свой собственный QList). Преобразование контейнеров в обоих направлениях может быть не лучшим решением.

Реализация собственного контейнера

Прочитав это, вы могли подумать: "Ну, я уверен, что могу сделать что-то лучше для моего конкретного случая, чем это делает STL". WAIT!

Реализация вашего контейнера правильно становится очень быстро огромной задачей: речь идет не только о том, как что-то работает, возможно, вам придется:

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

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

Использование сторонней библиотеки

Не STL не обязательно означает обычай. В сети много хороших библиотек, некоторые даже с разрешительной лицензией с открытым исходным кодом.

Добавление или отсутствие дополнительной сторонней библиотеки - это еще одна тема, но ее стоит рассмотреть.