c++ - program - ¿Cuándo debería usar un STL distinto al que viene con su compilador?

stl class c++ (13)

Tenía curiosidad por las implementaciones de STL fuera de lo que está empaquetado con gcc o Visual Studio, por lo que una rápida búsqueda en Google arrojó algunos resultados, como:

¿Bajo qué circunstancias se debe usar una biblioteca de plantillas estándar alternativa?

Por ejemplo, la página de Apache tiene una lista que incluye elementos como "conformidad total con el estándar de C ++" y "optimizada para compilaciones rápidas y tamaños de archivos ejecutables extremadamente pequeños". Si es tan bueno, ¿por qué no reemplazaría a libstdc ++?

En aras de la integridad, aquí están algunas de las otras implementaciones de STL:

STLPort
STXXL (que es una especie de propósito especial, destinado a grandes conjuntos de datos que no caben en la memoria)
Dinkumware (comercial)
SGI STL
libstdc++ (implementación de GCC)

A veces uso STLPort lugar del STL que se envía con Visual Studio. Cuando VC6 era compatible, la STL que venía con él tenía errores y, por lo tanto, usar STLPort (u otra STL) tenía mucho sentido (especialmente si estaba creando un código de múltiples subprocesos).

Ahora a menudo se trata más de rendimiento (tamaño o velocidad). Por ejemplo, la STL que se envía con VS2008 no es tan amigable en una situación de subprocesos múltiples, ya que utiliza el bloqueo alrededor de los objetos de configuración regional, lo que causa cosas que no esperaría sincronizar entre los subprocesos. (Vea aquí Convierta un número en una cadena con una longitud especificada en C ++ para obtener detalles de un ejemplo de esto).

Actualmente estamos usando STLPort - implementación externa de STL porque tenemos que usar (por varias razones) el antiguo compilador de Microsoft Visual C ++ 6.0 (fecha de lanzamiento de 1998) y la biblioteca suministrada por el compilador (por Dimkunware) está, por supuesto, muy obsoleta.

Aparte de las razones ya mencionadas, podría imaginar usar un STL diferente debido al soporte de depuración o como una forma de garantizar que no confiaba en las extensiones de los proveedores.

También sería un primer paso para comprobar si una biblioteca que estaba enviando funcionó bien en otras plataformas.

La biblioteca estándar de C ++ se puede implementar de varias maneras. Algunos implementadores tratan de hacer frente a las ideas modernas. Por lo tanto, el uso de una implementación optimizada puede resultar en ejecutables más rápidos y más pequeños.

Tome SCARY por ejemplo. Algunos implementadores no lo han hecho todavía, aunque reduce la hinchazón de STL en gran medida. Cuando haces lo siguiente:

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);

Una implementación "antigua" podría producir dos funciones de count diferentes en el ejecutable del resultado, porque el tipo de f no es el mismo que el de s . Eso es porque el tipo de iterador depende del tipo del vector en sí, aunque no necesita ser así. Una mejor idea es separar el tipo de iterador en una clase separada, y proporcionar un typedef en vector , y el compilador producirá un solo count . Eso fue solo un ejemplo, pero creo que hay más que decir acerca de la calidad de algunas implementaciones.

Las personas que mencionan STLport han mencionado el rendimiento y la portabilidad, pero también hay un modo de depuración bastante bueno disponible. Creo que esa es una buena razón para usar una STL diferente, si la biblioteca de su compilador actual está limitada de esta manera.

Aaand ... ¡parece que Max y yo terminamos de mencionar la depuración! ; ^) ~

Los terceros pueden implementar versiones mejoradas de STL que intentan ofrecer varias cosas, como un tamaño más pequeño, una ejecución más rápida, etc. Puede elegir una de estas implementaciones alternativas porque quiere uno de esos atributos de su implementación. También puede elegir uno de ellos al realizar el desarrollo multiplataforma porque desea evitar encontrarse con diferencias de comportamiento entre las versiones gcc y Visual Studio de su producto (como solo un ejemplo).

No hay necesidad de esperar una nueva versión de un compilador con una implementación de STL para poder alcanzar una nueva implementación si tiene necesidades específicas.

Nunca tuve la necesidad de usar una STL alternativa, pero podría imaginar algunos escenarios en los que podría ser útil usar, por ejemplo, la versión de Apache, si necesita pequeños ejecutables porque está desarrollando para una plataforma integrada.

Otra razón podría ser usar una versión STL que garantice ciertas cosas que no están necesariamente garantizadas por la norma. Por ejemplo, para asegurarse de que tiene cadenas que no sean COW para que pueda escribir código seguro para subprocesos.

Nunca tuve que usar una versión STL diferente a la que viene con el compilador. Pero aquí hay algunos puntos que vienen a mi mente.

Seguridad de subprocesos : el STL de apache proporciona un interruptor de compilación para activar / desactivar algunas características de seguridad de subprocesos.
Localización : una vez más, el STL de Apache viene con un buen soporte para muchos entornos locales diferentes.
Estructuras de datos : es posible que necesite una implementación de basic_string basada en COW (copia en escritura) y la versión STL que viene con su compilador no ofrece eso.
Extensiones no estándar : características particulares que le gustan de otras implementaciones de STL. Por ejemplo, las versiones de hash_map (y relacionadas) de Dinkumware (que se incluye con Visual Studio) tienen un diseño significativamente diferente de hash_map (y relacionados) de STLPort .
Problemas binarios : restricciones en algún entorno (software integrado) debido al tamaño del código. En tal caso, si no necesita la STL completa, puede ser interesante utilizar una versión reducida.
Rendimiento : Qué sucede si descubre, después de la creación de perfiles, que la "otra" implementación de STL le proporciona un rendimiento significativamente mejor para una aplicación en particular. (Con tantos detalles sobre algoritmos y estructuras de datos, esto podría ser posible).
Modo de depuración : algunas implementaciones de STL proporcionan buenas características para la depuración. Por ejemplo, comprobando rangos de iteradores.

STLPort admite archivos de más de 2 GB a través de std :: fstreams. Visual Studio 2005/2008 no puede manejar archivos de más de 2 GB.

Puede probar su implementación de STL mostrando: std::numeric_limits<std::streamsize>::max()

Tanto MSVC ++ como GNU g ++ vienen con implementaciones bastante buenas de la biblioteca estándar de C ++, pero hay compiladores que no, y si tuviera que admitir tales compiladores buscaría una implementación de STL de terceros.

Una de las razones es para una mejor seguridad del hilo. Estaba usando la STL predeterminada que venía con Visual Studio (VC6 infact), luego tuve que cambiar a STLPort porque tenía mucha mejor seguridad para subprocesos.

Varias personas han mencionado la depuración en cuanto a la capacidad de activar información de diagnóstico adicional. Sin embargo, otro aspecto importante es que si utiliza la STL propia de la plataforma, puede obtener una mejor experiencia en el depurador. Esto es especialmente cierto si está utilizando Visual Studio, que tiene visualizadores para todos los contenedores estándar.

STLport tiene lo que ellos llaman un "modo de depuración de energía" que realiza una gran cantidad de tiempo de ejecución para verificar "la corrección de los iteradores y el uso de contenedores". Ayuda a atrapar una serie de errores que no serían inmediatamente obvios. Recomiendo altamente el uso de STLport durante la depuración y la prueba.