c++ - gratis - Para STL o! STL, esa es la pregunta

stl gratis (14)

Comencé 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ódigo 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.

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

Cuanto más pensaba en ello, más me daba cuenta de que quizás DEBERÍA haber casos en los que decidiera 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 ... Quizás un La solución de contenedor personalizado que se ajusta con precisión a las necesidades del proyecto ¿vale la pena la carga inicial? ¿Qué opinas? ¿Hay algún caso en el que elegirías NO STL?

Creo que es un escenario típico de compilación vs 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 hacer mi propia versión. Debería concentrar la mayor parte de su esfuerzo en lo que hace su aplicación, no en los componentes básicos que utiliza.

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

Hay tantas ventajas al usar stl. Para un proyecto a largo plazo, los beneficios superan los costos.

Los nuevos programadores pueden comprender los contenedores desde el primer día, dándoles más tiempo para aprender el otro código en el proyecto. (suponiendo que ya conocen STL como lo haría cualquier programador competente de C ++)
La reparación de errores en los contenedores es una pérdida y desperdicio de tiempo que podría emplearse para mejorar la lógica comercial.
Lo más probable es que no los escriba así como el 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 al mismo tiempo y no es necesario serializar el acceso al contenedor.

He encontrado problemas al usar STL en código multiproceso. Incluso si no comparte objetos STL entre subprocesos, muchas implementaciones utilizan construcciones que no son seguras para subprocesos (como ++ para el recuento de referencias en lugar de un estilo de incremento entrelazado, o que tienen asignadores no seguros para subprocesos).

En cada uno de estos casos, aún opté por usar 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 modo que pueda usar algoritmos y otras funciones STL que operen solo en iteradores.

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 tanto, decidimos no presentarla ahora.

Las razones principales para no usar STL son las siguientes:

Su implementación en C ++ es antigua y tiene un soporte de plantilla horrible.
No puede usar la asignación de memoria dinámica.

Ambos son requisitos muy poco comunes en la práctica.

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

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 elegir 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.

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.

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.

Una situación donde 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.

Codificando para Symbian.

STLPort es compatible con Symbian 9, por lo que el caso contra 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 de Symbian, por lo que puede ser más problemático que simplemente haciendo 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 ++".

El estándar C ++ perversamente permite implementaciones de algunas operaciones de iterador para lanzar excepciones . 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.

Introducción:

STL es una gran biblioteca, y útil en muchos casos, pero definitivamente no resuelve todas las situaciones. Responder a 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 contenedor que se ajusta a una solución determinada.
Está bien documentado
Es bien sabido (los programadores generalmente ya lo saben, entrar en un proyecto es más corto)
Está probado y estable.
Es una plataforma cruzada
Se incluye con cada compilador (no agrega una tercera dependencia de biblioteca)
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 de acceso simultáneo a través de 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: retransmisión de STL en excepciones, por lo que si por alguna razón no puede aceptar excepciones (por ejemplo, seguridad crítica), no puede usar 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 una estructura de datos específica (aún no incluida): gráfico, árbol, etc.
Restricciones especiales de complejidad: puede descubrir que el contenedor de propósito general STL 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 (p. Ej., El bloqueo lector-escritor no se puede (fácilmente) utilizar debido al [] operator 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 ajustarse a sus necesidades, pero el cambio también es cierto: debe cumplir con las necesidades de STL. No intente usar std::vector en un microcontrolador integrado 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.

Implementando su propio contenedor

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

La implementación correcta de su contenedor se convierte muy rápidamente en una gran tarea: no solo se trata de implementar algo que funcione, es posible que deba:

Documentarlo profundamente, incluidas las limitaciones, la complejidad del algoritmo, etc.
Esperar errores y resolverlos
Necesidades adicionales entrantes: ya sabe, esta función falta, esta conversión entre tipos, etc.
Después de un tiempo, es posible que desee refactorizar y cambiar todas las dependencias (¿demasiado tarde?)
....

Código utilizado que en el fondo del código como un contenedor es definitivamente algo que lleva tiempo implementar, y debe ser cuidadosamente.

Usando una biblioteca de terceros

No STL no significa necesariamente personalizado. 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.