Para STL o! STL, esa es la pregunta

Question

Indiscutiblemente, elegiría usar el STL para la mayoría de los proyectos de programación en C++. La pregunta me fue presentada recientemente, sin embargo, "¿Hay algún caso en el que no usaría el STL?" ...

Cuanto más lo pensaba, más me daba cuenta de que quizás DEBERÍA haber casos en los que elija no usar el STL ... Por ejemplo, un proyecto realmente grande y de largo plazo cuya base de código se espera que dure años ... ¿Tal vez una solución de contenedor personalizado que se adapte exactamente a las necesidades del proyecto vale la pena la carga inicial? ¿Qué opinas? ¿Hay algún caso en el que elegirías NO STL?

Answer 1

Los proyectos con requisitos estrictos de memoria, como los sistemas integrados, pueden no ser adecuados para el STL, ya que puede ser difícil controlar y administrar lo que se extrae y se devuelve al montón. Como Evan mencionó, escribir asignaturas adecuadas puede ayudar con esto, pero si está contando cada byte utilizado o preocupado con la fragmentación de la memoria, puede ser más inteligente rodar manualmente una solución que se adapte a su problema específico, ya que el STL se ha optimizado para el uso más general.

También puede optar por no utilizar STL para un caso particular porque existen más contenedores aplicables que no están en el estándar actual, como boost :: array o boost :: unordered_map.

Answer 2

Por lo general, creo que la mejor opción es utilizar el AWL con asignadores personalizados en lugar de reemplazar los contenedores STL con los rodados a mano. Lo bueno del STL es que pagas solo por lo que usas.

Answer 3

Creo que es un escenario típico de compilación versus compra. Sin embargo, creo que en este caso casi siempre 'compraría', y usaría STL, o una mejor solución (algo de Boost, tal vez), antes de poner en marcha el mío. Debería concentrar la mayor parte de su esfuerzo en lo que hace su aplicación, no en los componentes básicos que utiliza.

Answer 4

Las principales razones para no usar STL son las siguientes: aplicación

1. Su C++ es antiguo y tiene el apoyo de plantilla horrible.
2. No puede usar la asignación de memoria dinámica.

Ambos son requisitos poco comunes en la práctica.

Para un proyecto a largo plazo enrollar sus propios contenedores que se superponen en funcionalidad con el STL solo va a aumentar los costos de mantenimiento y desarrollo.

Answer 5

Realmente no lo creo. Al hacer mis propios contenedores, incluso intentaría hacerlos compatibles con el STL porque el poder de los algoritmos genéricos es demasiado grande como para rendirme. El STL debería al menos ser utilizado nominalmente, incluso si todo lo que hace es escribir su propio contenedor y especializar cada algoritmo para ello. De esta forma, cada algoritmo de clasificación puede invocarse sort (c.begin(), c.end()). Si se especializa ordenar para tener el mismo efecto, incluso si funciona de manera diferente.

Answer 6

He encontrado problemas al utilizar STL en código de subprocesos múltiples. Incluso si no comparte objetos STL a través de subprocesos, muchas implementaciones utilizan construcciones que no son seguras para subprocesos (como ++ para el recuento de referencias en lugar de un estilo de incremento interconectado o que tienen asignadores no seguros para subprocesos).

En cada uno de estos casos, aún opté por utilizar STL y solucionar los problemas (hay suficientes ganchos para obtener lo que desea).

Incluso si opta por crear sus propias colecciones, sería una buena idea seguir el estilo STL para los iteradores, de forma que pueda usar algoritmos y otras funciones STL que operen solo en iteradores.

Answer 7

El uso del stl tiene tantas ventajas. Para un proyecto a largo plazo, los beneficios superan los costos.

1. Los nuevos programadores pueden comprender los contenedores desde el primer día, lo que les da más tiempo para aprender el otro código del proyecto. (suponiendo que ya conocen STL como lo haría cualquier programador competente de C++)
2. La reparación de errores en los contenedores es una pérdida y un desperdicio de tiempo que podría emplearse para mejorar la lógica comercial.
3. Lo más probable es que no los escriba así como la STL se implementa de todos modos.

Dicho esto, los contenedores STL no se ocupan de la concurrencia en absoluto. Por lo tanto, en un entorno donde necesite concurrencia, usaría otros contenedores como los contenedores concurrentes de Intel TBB. Estos son mucho más avanzados con el bloqueo de grano fino de modo que diferentes hilos pueden modificar el contenedor simultáneamente y no es necesario serializar el acceso al contenedor.

Answer 8

La mayoría de los proyectos en los que he trabajado tenían una base de código mucho más antigua que cualquier versión realmente utilizable de STL, por lo que decidimos no presentarla ahora.

Answer 9

El problema principal que he visto es tener que integrar con el código heredado que se basa en el operador no tirar nuevo.

Answer 10

Empecé a programar C en alrededor de 1984 y nunca he usado el STL. A lo largo de los años, he desarrollado mis propias bibliotecas de funciones y han evolucionado y crecido cuando el STL aún no era estable o carecía de soporte multiplataforma. Mi biblioteca común ha crecido para incluir códigos de otros (principalmente cosas como libjpeg, libpng, ffmpeg, mysql) y algunos otros y prefiero mantener la cantidad de código externo en él al mínimo. Estoy seguro de que ahora el STL es genial, pero francamente estoy contento con los elementos de mi caja de herramientas y no veo la necesidad en este momento de cargarlo con más herramientas. Pero ciertamente veo los grandes saltos que los nuevos programadores pueden hacer al usar el STL sin tener que codificar todo desde cero.

Answer 11

Una situación en la que esto puede ocurrir es cuando ya está utilizando una biblioteca externa que ya proporciona las capacidades que necesita de STL. Por ejemplo, mi empresa desarrolla una aplicación en áreas de espacio limitado y ya usa Qt para el juego de herramientas de ventanas. Como Qt proporciona clases de contenedores similares a STL, las utilizamos en lugar de agregar STL a nuestro proyecto.

Answer 12

Codificación para Symbian.

STLPort es compatible con Symbian 9, por lo que el uso de STL es más débil de lo que solía ser ("no está disponible" es un caso bastante convincente), pero STL sigue siendo ajeno a todas las bibliotecas Symbian, por lo que puede más problemas que simplemente hacer las cosas de la manera Symbian.

Por supuesto, podría argumentarse sobre estas bases que la codificación de Symbian no es "un proyecto de programación en C++".

Answer 13

El estándar C++ perversamente permite implementaciones de algunos iterator operations to throw exceptions. Esa posibilidad puede ser problemática en algunos casos. Por lo tanto, puede implementar su propio contenedor simple que garantice no lanzar excepciones para operaciones críticas.

Answer 14

Introducción:

STL es una gran biblioteca, y útil en muchos casos, pero definitivamente no resuelven todas las situaciones. ¡Respondiendo STL o!STL es como responder "¿Cumple STL con tu necesidad o no?"

Pros de STL

• En la mayoría de las situaciones, STL tiene un recipiente que se ajustan para una solución dada.
• Está bien documentado
• Es bien sabido (programadores por lo general ya lo saben, entrar en un proyecto es más corto)
• Se ha probado y estable.
• Es multiplataforma
• Se incluye con cada compilador (no agregar una tercera dependencias de bibliotecas)
• STL ya está implementado y listo
• STL es brillante, ...

Contras de STL

No importa que necesite un simple Gráfico, Árbol Rojo-Negro, o una base de datos muy compleja de elementos con un AI que administre acceso concurrente th en bruto una computadora cuántica. El hecho es que STL no lo hace, y nunca resolverá todo.

Los siguientes aspectos son solo algunos ejemplos, pero básicamente son consecuencia de este hecho: STL es una biblioteca real con límites.

• Excepciones: relé STL sobre las excepciones, por lo que si por alguna razón usted no puede aceptar excepciones (por ejemplo, la seguridad crítico), no se puede utilizar STL. ¡Derecha! las excepciones pueden deshabilitarse, pero eso no resuelve el diseño de la retransmisión de STL en ellas y eventualmente llevará a un bloqueo.

• Necesidad de concreto (no incluido) estructura de datos: gráfico, árbol, etc.

• limitaciones especiales de complejidad: Usted podría descubrir que STL contenedor de propósito general no es el más óptimo para su código de cuello de botella.

• Consideraciones de concurrencia: o necesita concurrencia y STL no proporciona lo que necesita (por ejemplo, el bloqueo lector-escritor no se puede (fácilmente) utilizar debido al bidireccional [] operator). O puede diseñar un contenedor que se beneficie de multi-threading para un acceso/búsqueda/inserción/lo que sea mucho más rápido.

• STL necesita satisfacer sus necesidades, pero el cambio también es cierto: debe cumplir con las necesidades de STL. No intente utilizar std::vector en un microcontrolador incorporado con 1K de RAM no administrada.

• Compatibilidad con otras bibliotecas: puede ser que, por razones históricas, las bibliotecas que utiliza no acepten STL (por ejemplo, QtWidgets hace un uso intensivo de su propia QList). Convertir contenedores en ambas direcciones podría no ser la mejor solución.

---

la implementación de su propio contenedor

Después de leer esto, usted podría pensar: "Bien, estoy seguro de que puedo hacer algo mejor para mi caso específico de STL hace." ¡ESPERE!

La implementación de su contenedor convertido correctamente muy rápidamente en una tarea enorme: es no sólo acerca de cómo implementar algo de trabajo, puede que tenga que:

• Documento profundamente, incluyendo limitaciones, complejidad del algoritmo, etc.
• esperar errores, y les resolver
• necesidades adicionales entrantes: usted sabe, esta función que falta, esta conversión entre tipos, etc.
• Después de un tiempo, usted podría querer refactorizar, y cambiar todas las dependencias (demasiado tarde?)
• ....

código utilizado que en el fondo en el código como un contenedor es definitivamente algo que toma tiempo para poner en práctica, y debe ser, aunque con cuidado.

---

El uso de la biblioteca tercera parte

No STL no significa necesariamente que la costumbre. Hay muchas bibliotecas buenas en la red, algunas incluso con licencia permisiva de código abierto.

Agregar o no una biblioteca adicional de terceros es otro tema, pero vale la pena ser considerado.