c++ - nuevo - ¿Cuándo deben usarse los algoritmos STL en lugar de usar los suyos?
nuevo algoritmo de instagram 2018 (13)
Con frecuencia uso los contenedores STL, pero nunca he usado los algoritmos STL que se van a usar con los contenedores STL.
Una de las ventajas de usar los algoritmos STL es que proporcionan un método para eliminar los bucles y así reducir la complejidad de la lógica del código. Hay otros beneficios que no voy a enumerar aquí.
Nunca he visto el código C ++ que utiliza los algoritmos STL. Desde el código de muestra en los artículos de la página web hasta los proyectos de código abierto, no he visto su uso.
¿Se usan con más frecuencia de lo que parece?
¿Cuándo deben usarse los algoritmos STL en lugar de usar los suyos?
Cuando valoras tu tiempo y cordura y tienes más cosas divertidas que hacer que reinventar la rueda una y otra vez.
Debe usar sus propios algoritmos cuando el proyecto lo requiere, y no hay alternativas aceptables para escribir cosas por sí mismo, o si identificó el algoritmo STL como un cuello de botella (por supuesto, usando un generador de perfiles), o tiene algún tipo de restricciones que STL no tiene. cumplir con, o adaptar STL para la tarea llevará más tiempo que escribir el algoritmo desde cero (tuve que usar la versión retorcida de la búsqueda binaria pocas veces ...). STL no es perfecto y no sirve para todo, pero cuando puede, debe usarlo. Cuando alguien ya hizo todo el trabajo por usted, a menudo no hay razón para volver a hacer lo mismo.
¿Se usan con más frecuencia de lo que parece?
Nunca los he visto usados; excepto en los libros. Tal vez se utilizan en la implementación de la propia STL. Tal vez se usen más porque son más fáciles de usar (ver, por ejemplo, las funciones y expresiones de Lambda ), o incluso se vuelven obsoletas (vea, por ejemplo, el bucle for-loop basado en rango ), en la próxima versión de C ++.
Cuando crees que puedes codificarlo mejor que un codificador realmente inteligente que pasa semanas investigando y probando y tratando de hacer frente a cada conjunto de entradas concebible.
¡Para la mayoría de los terrícolas la respuesta es NUNCA!
El principal problema con los algoritmos STL hasta ahora era que, a pesar de que el algoritmo se llama a sí mismo es más claro, definir los funtores que necesitaría pasarles haría que su código fuera más largo y más complejo, debido a la forma en que el lenguaje lo obligó a hacerlo. hazlo. Se espera que C ++ 0x cambie eso, con su soporte para las expresiones lambda.
He estado usando STL en gran medida durante los últimos 6 años y aunque intenté usar los algoritmos de STL en cualquier lugar que pudiera, en la mayoría de los casos haría que mi código fuera más oscuro, así que volví a un ciclo simple. Ahora con C ++ 0x es todo lo contrario, el código parece parecer siempre más sencillo con ellos.
El problema es que por ahora el soporte de C ++ 0x todavía está limitado a algunos compiladores, incluso porque el estándar aún no está completamente terminado. Probablemente tendremos que esperar algunos años para ver realmente el uso generalizado de los algoritmos STL en el código de producción.
Escribo aplicaciones críticas de rendimiento. Estos son el tipo de cosas que necesitan procesar millones de datos en el menor tiempo posible. No podría hacer algunas de las cosas que hago ahora si no fuera por STL. Utilízalos siempre.
Hay muchos buenos algoritmos además de cosas como std::foreach .
Sin embargo, hay muchos algoritmos no triviales y muy útiles:
- Clasificación:
std::sort,std::upper_bound,std::lower_bound,std::binary_search - Mín. / Máx.
std::max,std::min,std::partition,std::min_element,std::max_element - Busca como
std::find,std::find_first_ofetc.
Y muchos otros.
Los algoritmos como std::transform son muy útiles con las expresiones lambda C ++ 0x o cosas como boost::lambda o boost::bind
La única vez que no utilizo los algoritmos STL es cuando las diferencias de implementación multiplataforma afectan el resultado de mi programa. Esto solo ha ocurrido en uno o dos casos raros (en la Playstation 3). Aunque la interfaz de la STL está estandarizada en todas las plataformas, la implementación no lo está.
Además, en ciertas aplicaciones de rendimiento extremadamente alto (piense: videojuegos, servidores de videojuegos), reemplazamos algunas estructuras STL con las nuestras para ofrecer un poco más de eficiencia.
Sin embargo, la gran mayoría de las veces usando STL es el camino a seguir. Y en mis otros trabajos (no de videojuegos), usé el STL exclusivamente.
Los algoritmos STL deben utilizarse siempre que se ajusten a lo que necesita hacer. Que es casi todo el tiempo.
No usaría STL en dos casos:
Cuando STL no está diseñado para su tarea. STL es casi lo mejor para propósitos generales. Sin embargo, para aplicaciones específicas, STL puede no ser siempre el mejor. Por ejemplo, en uno de mis programas, necesito una tabla hash enorme, mientras que la equivalencia de hashmap de STL / tr1 requiere demasiada memoria.
Cuando estás aprendiendo algoritmos. Soy uno de los pocos que disfrutan reinventando las ruedas y aprenden mucho en este proceso. Para ese programa, reimplementé una tabla hash. Realmente me tomó mucho tiempo, pero al final todos los esfuerzos dieron resultado. He aprendido muchas cosas que benefician enormemente mi futura carrera como programador.
Respuesta corta: Siempre.
Respuesta larga: siempre. Para eso están ellos. Están optimizados para su uso con contenedores STL, y son más rápidos, más claros y más idiomáticos que cualquier cosa que pueda escribir usted mismo. La única situación que debería tener en cuenta es si puede articular una necesidad muy específica y de misión crítica que los algoritmos de STL no satisfacen.
Editado para agregar: (Bueno, realmente no siempre, pero si tiene que preguntar si debe usar STL, la respuesta es "sí").
Si tuviera que escribir algo para esta tarde, y supiera cómo hacerlo utilizando bucles hechos a mano y necesitaría averiguar cómo hacerlo en algoritmos STL, lo escribiría utilizando bucles hechos a mano.
Habiendo dicho eso, trabajaría para hacer que los algoritmos STL sean una parte confiable de mi conjunto de herramientas, por razones expresadas en las otras respuestas.
-
Las razones por las que podría no verlo en el código es que es un código heredado o escrito por programadores heredados. Tuvimos unos 20 años de programación en C ++ antes de que saliera el STL, y en ese momento teníamos una comunidad de programadores que sabían cómo hacer las cosas a la manera antigua y aún no habían aprendido el método de STL. Esto probablemente se mantendrá por una generación.
Tenga en cuenta que los algoritmos STL cubren muchas bases, pero la mayoría de los desarrolladores de C ++ probablemente terminarán codificando algo que hace algo equivalente a std::find() , std::find_if() y std::max() casi todos El día de su vida laboral (si todavía no están utilizando las versiones STL). Al usar las versiones STL, separa el algoritmo tanto del flujo lógico de su código como de la representación de datos .
Para otros algoritmos STL de uso menos común, como std::merge() o std::lower_bound() estas son rutinas sumamente útiles (la primera para fusionar dos contenedores ordenados, la segunda para averiguar dónde insertar un elemento en un contenedor para mantenerlo ordenado). Si intentara implementarlas usted mismo, probablemente tomaría algunos intentos (los algoritmos no son complicados, pero probablemente obtendría errores de uno en uno o similares).
Yo mismo los uso todos los días de mi carrera profesional. Es posible que algunas bases de código heredadas que preceden a un STL estable no lo usen de manera extensiva, pero si hay un proyecto más nuevo que intencionalmente lo evite, me sentiría inclinado a pensar que fue un pirata informático de medio tiempo que aún estaba trabajando bajo el supuesto de mediados de los 90 Que las plantillas son lentas y por lo tanto hay que evitarlas.
Ya has recibido varias respuestas, pero realmente no puedo estar de acuerdo con ninguna de ellas. Algunos se acercan bastante a la marca, pero no mencionan el punto crucial (IMO, por supuesto).
Al menos para mí, el punto crucial es bastante simple: debes usar los algoritmos estándar cuando ayudan a aclarar el código que estás escribiendo.
Es realmente tan simple. En algunos casos, lo que está haciendo requiere una invocación arcana usando std::bind1st y std::mem_fun_ref (o algo en ese orden) que es extremadamente denso y opaco, donde un bucle for sería casi trivialmente simple y directo. En tal caso, siga adelante y use el bucle for .
Si no hay un algoritmo estándar que haga lo que usted quiere, cuídese y vuelva a mirar: a menudo habrá omitido algo que realmente hará lo que quiere (un lugar que a menudo se omite: los algoritmos en <numeric> menudo son útiles para usos no numéricos). Habiendo examinado un par de veces y confirmando que realmente no hay un algoritmo estándar para hacer lo que quiere, en lugar de escribirlo for (o lo que sea), considere escribir un algoritmo genérico para hacer lo que necesita que se haga. Si lo usas en un solo lugar, hay muchas posibilidades de que puedas usarlo dos o tres más, momento en el que puede ser una gran victoria en claridad.
Escribir algoritmos genéricos no es tan difícil, de hecho, a menudo casi no es un trabajo extra comparado con escribir un bucle en línea, por lo que incluso si solo puede usarlo dos veces, ya está ahorrando un poco de trabajo, incluso si Ignora la mejora en la legibilidad y claridad del código.