¿Es práctico abandonar STL en el desarrollo de C ++? [cerrado]

Sé que en algunas áreas (industria de juegos, por ejemplo), no se recomienda STL. Entonces mi pregunta es: ¿es realmente una buena práctica no usar STL en algunos casos? Si es así, ¿cuáles son las principales razones para no usar el STL moderno de C ++?

• Solo se me ocurre una razón válida y es realmente raro: el tiempo real difícil. Muchas cosas en la biblioteca estándar asignan memoria internamente y eso no es lo suficientemente determinista para aplicaciones en tiempo real difíciles, por lo que deben evitarse. Estas aplicaciones suelen ser bastante simples, aunque tardan un tiempo desproporcionado en desarrollarse debido a la rigurosa revisión y prueba.

• Puedo pensar en una razón inválida, pero muy común: los desarrolladores que no entienden la complejidad computacional, usan indebidamente STL y luego culpan a la biblioteca.

  STL suele ser más rápido en tiempo de ejecución que las soluciones de estilo C con punteros de devolución de llamada o soluciones basadas en polimorfismo con métodos virtuales ( consulte también la nota clave de Bjarne Stroustrup ). Sin embargo, cuando el desarrollador no comprende las especificaciones de complejidad dadas y hace un mal uso de la biblioteca creando algo así como el vector de vectores de algunos objetos complejos (¡en C ++ 11 ya no es un problema!), Causa un problema de rendimiento y luego se defiende con "ves, los vectores son bastante lentos", puede causar una percepción de que la biblioteca estándar es lenta. Y una vez que los gerentes obtienen esa percepción, puede vivir mucho tiempo en la organización.

• Obviamente, no puede usar nada que la plataforma a la que apunta no sea compatible. Sin embargo, actualmente apuntamos a las cuatro plataformas móviles más comunes (Android, iOS, Bada y WinCE anterior) y usamos la biblioteca estándar y algunas partes de Boost en todas ellas.

  Gran parte de la biblioteca estándar solía no ser compatible con Microsoft a principios de WinCE (los iostreams IIRC solo salieron con Visual Studio 2005), pero en su lugar era posible usar STLport mucho antes. Y generalmente puede hacer que se compile para cualquier cosa. Entonces llamaría a esta razón inválida también.

  Además, durante bastante tiempo no es "STL", sino ANSI C ++ Standard Library. Está definido por el mismo documento estándar que define el lenguaje en sí. Todo lo que no lo admite no merece llamarse C ++.

Estoy usando STL y boost por muchos años ya. Si quisiera abandonarlo y usar mis herramientas personalizadas, la motivación sería:

1. Reducción del tiempo de compilación (75%). Solo incluir iostreams puede agregar 1 millón de líneas de código a su módulo. Sí, los encabezados precompilados ayudan mucho, pero aún así ralentiza mucho la compilación en grandes proyectos. A la larga, desperdicia mucho tiempo de cualquiera que trabaje en él.
2. Actuación. (25%) STL está escrito para funcionar en general, pero puede optimizar sus estructuras para que funcionen exactamente como lo desee. Por ejemplo, puede tener estructuras de datos con millones de cadenas cortas. Puede ser mucho más rápido usar una clase de cadena personalizada basada en el principio de boost :: small_vector (vector local de datos estático pequeño, asignación dinámica solo para cadenas más grandes), este tipo de cambios puede hacer que las secciones críticas del código funcionen muchas veces más rápido.

Hay una gran razón válida para no usar la biblioteca de plantillas estándar de C ++: una de sus plataformas de destino no tiene una implementación totalmente compatible (o ninguna implementación) y usted sabe que no obtendrá una. dentro de los próximos años.

No sé acerca de la complejidad (eficiencia de implementación), pero estoy usando contenedores y cadenas Qt ampliamente en lugar de los estándar y funcionan bien. También encuentro que la implementación Qt de conjuntos y listas es más fácil de usar.

Por lo tanto, puede ser práctico abandonar el STL si puede usar otra biblioteca que se ajuste a sus necesidades.

Patrick ha mencionado la razón para no usar todo el STL, es decir, que su (s) plataforma (s) no tiene uno.

En general, creo que la pregunta no tiene sentido. En general, no es una decisión de todo o nada, sino de elegir y elegir. Es posible que decida utilizar los contenedores y los algoritmos, pero decida usar algo fuera de Std Lib para cadenas e I / O.

No es práctico, a menos que haya una razón importante para hacerlo. Algunas de las razones en las que puedo pensar incluyen solo la implementación parcial o inexistente de STL (o cualquier otra parte de la biblioteca estándar) o una limitación de recursos (memoria, velocidad de CPU, almacenamiento, ...) que debe sortear rodar sus propias herramientas que se adhieren a lo que necesita lograr.

En la industria de los juegos, la mayoría de los estudios (incluso más pequeños hasta cierto punto) tienen sus bibliotecas internas e implementaciones de muchas partes de la biblioteca estándar que están muy adaptadas para la plataforma objetivo y, en algunos casos, para el engnie objetivo o incluso para el juego en sí. En pocas palabras, al desarrollar un juego para consolas, el hardware está muy limitado por los estándares actuales. Hay miles y miles de líneas de ensamblaje hecho a mano por una razón. Es muy importante minimizar todo tipo de huellas de recursos en su código para que el juego se ejecute más rápido, lo que permite más contenido en el mundo del juego (o en un mundo más grande, por ejemplo), lo que con suerte resulta en un mejor producto.

"Cada juego exitoso comienza implementando su propia implementación de la lista vinculada".