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

Question

Мне было любопытно узнать о реализации STL за пределами того, что упаковано в gcc или Visual Studio, поэтому быстрый поиск в Google нашел несколько результатов, таких как:

• Apache stdcxx
• USTL
• rdeSTL

При каких обстоятельствах следует использовать альтернативную стандартную библиотеку шаблонов?

Например, на странице Apache есть список, включающий такие элементы, как «полное соответствие стандарту C ++» и «оптимизированный для быстрой компиляции и чрезвычайно малых размеров исполняемых файлов». Если это так хорошо, почему бы не заменить libstdc ++?

---

Для полноты, вот некоторые из других реализаций STL:

• STLPort
• STXXL (что является своего рода специального назначения, предназначенного для больших наборов данных, которые не помещаются в памяти)
• Dinkumware (коммерческий)
• SGI STL
• libstdc ++ (реализация GCC)

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

Answer 10

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