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

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Возьмите 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 в vector, а компилятор будет производить только один count. Это был всего лишь пример, но я думаю, что есть еще что сказать о качестве некоторых реализаций.

Ответ 7

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

Это был бы также первый шаг в тестировании того, хорошо ли работала библиотека, которую я отправлял на других платформах.

Ответ 8

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

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

Ответ 9

В настоящее время мы используем STLPort - внешнюю реализацию STL, потому что нам приходится использовать (по разным причинам) довольно старый компилятор Microsoft Visual С++ 6.0 (дата выпуска 1998 года) и библиотека, поставляемая компилятором (Dimkunware), конечно, очень устарели.

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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