Когда необходимо использовать STL кроме того, который идет компилятором?

Мне никогда не приходилось использовать версию STL, кроме той, которая была упакована вместе с компилятором. Но вот некоторые моменты, которые приходят мне в голову.

• Безопасность потоков : STL от apache предоставляет переключатель компиляции для включения / выключения некоторых функций безопасности потоков.
• Локализация : Опять же, STL от apache поставляется с хорошей поддержкой многих различных локалей.
• Структуры данных : вам может потребоваться реализация basic_string , основанная на COW (копирование при записи) и версии STL, которая поставляемый с вашим компилятором, не предлагает этого.
• Нестандартные расширения : особенности, которые вам нравятся в некоторых других реализациях STL. Например, hash_map (и связанные) версии от Dinkumware (который поставляется с Visual Studio) имеют дизайн, значительно отличающийся от hash_map (и связанных) от STLPort .
• Проблемы с двоичными файлами : ограничения в некоторой среде (встроенное программное обеспечение) из-за размера кода. В таком случае, если вам не нужен весь STL, может быть интересно использовать сокращенную версию.
• Производительность : Что, если вы обнаружите после профилирования, что «другая» реализация STL дает вам значительно лучше производительность для конкретного приложения. (При таком большом количестве деталей, касающихся алгоритмов и структур данных, это действительно возможно.)
• Режим отладки : Некоторые реализации STL предоставляют удобные возможности для отладки. Например, проверка диапазонов итераторов.

Иногда я использую STLPort вместо STL, который поставляется с Visual Studio. Раньше, когда VC6 поддерживался, поставляемый с ним STL был с ошибками, и поэтому использование STLPort (или другого STL) имело большой смысл (особенно если вы создавали многопоточный код).

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

I've never had a need to use an alternative STL, but I could envision some scenarios where it might be useful to use, for example, the Apache version, if you need small executables because you're developing for an embedded platform.

Another reason might be to use an STL version that guarantees certain things which are not necessarily guaranteed by the standard. For example, to ensure you have non-COW strings so you can write thread-safe code.

STLport имеет то, что они называют «режимом мощной отладки», который выполняет множество проверок во время выполнения на «правильность использования итераторов и контейнеров». Помогает отловить ряд ошибок, которые не сразу бросаются в глаза. Я настоятельно рекомендую использовать STLport при отладке и тестировании.

Третьи стороны могут реализовать улучшенные версии STL, которые пытаются предложить различные вещи, такие как меньший размер, более быстрое выполнение и т. Д. Вы можете выбрать одну из этих альтернативных реализаций, потому что вам нужен один из этих атрибутов их реализации. Вы также можете выбрать один из них при кроссплатформенной разработке, потому что вы хотите избежать различий в поведении между версиями gcc и Visual Studio вашего продукта (как только один пример).

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

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

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

vector<int> f;
vector<int, MyAllocator> s;

size_t fc = count(f.begin(), f.end(), SomeValue);
size_t sc = count(s.begin(), s.end(), SomeOtherValue);

«Старая» реализация может создать две разные функции count в исполняемом файле результата, потому что тип f не такой, как у ] s . Это потому, что тип итератора зависит от типа самого вектора, хотя это не обязательно. Лучше всего выделить тип итератора в отдельный класс, и предоставит typedef в векторе , и компилятор выдаст только один счетчик . Это был всего лишь пример, но я думаю, что есть еще кое-что, что можно сказать о качестве некоторых реализаций.

Aside from the reasons already given, I could imagine using a different STL due to debugging support or as a way to guarantee I was not relying on vendor extensions.

It would also be a first step in testing whether a library I was shipping worked well on other platforms.

Люди, упоминающие STLport, указали на производительность и переносимость, но также доступен довольно хороший режим отладки . Я думаю, что это отличная причина использовать другой STL, если ваша текущая библиотека компилятора ограничена таким образом.

Ааи ... похоже, мы с Максом связались с упоминанием об отладке! ; ^) ~

Одна из причин - лучший поток - безопасность. Я использовал STL по умолчанию, который поставлялся с Visual Studio (на самом деле VC6), затем мне пришлось перейти на STLPort, поскольку он имел гораздо лучшую безопасность потоков.

We are currently using STLPort - external implementation of STL because we have to use (for various reasons) quite old Microsoft Visual C++ 6.0 compiler (1998 release date) and compiler supplied library (by Dimkunware) is of course very out of date.

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

STLPort поддерживает файлы размером более 2 ГБ через std :: fstreams. Visual Studio 2005/2008 не может обрабатывать файлы размером более 2 ГБ.

Вы можете протестировать свою реализацию STL, отобразив: std :: numeric_limits :: max ()

И MSVC ++, и GNU g ++ поставляются с довольно хорошими реализациями стандартной библиотеки C ++, но есть компиляторы, которые этого не делают, и если бы мне пришлось поддерживать такие компиляторы, я бы поискал стороннюю реализация STL.