iteradores de C++ considerados dañinos?

Question

En la conferencia de la biblioteca de Boost hoy, Andrei Alexandrescu, autor del libro Modern C++ Design y la biblioteca Loki C++, dio una charla titulada "Iterators Must Go" (video, slides) sobre por qué los iteradores son malos y tuvo una mejor solución .

Intenté leer las diapositivas de la presentación, pero no pude obtener mucho de ellas.

1. ¿Los iteradores son malos?
2. ¿Es su reemplazo realmente mejor?
3. ¿Los implementadores de C++ recogerán sus ideas?

Answer 1

En primer lugar, para responder a sus preguntas:

1. No. De hecho, argumenté elsewhere que los iteradores son el concepto más importante/fundamental de la ciencia de la computación. Yo (a diferencia de Andrei) también creo que los iteradores son intuitivo.
2. Sí, definitivamente pero eso no debería ser una sorpresa.
3. Hmm. En cuanto a Boost.Range y C++ 0x, ¿no es cierto?

La gran contribución de Andrei aquí es solo decir: elimine el concepto de iteradores en conjunto, vea los rangos no solo como una envoltura de conveniencia sino como una construcción central. Otros lenguajes ya lo han hecho (muchos de los conceptos de Andrei solo hacen eco de LINQ de .NET o los iteradores de Python) pero todos solo ofrecen rangos de salida . Andrei defiende diferentes tipos de rangos, al igual que las categorías de iteradores convencionales.

En esa luz, es extraño que empiece burlándose de la arbitrariedad de estas categorías de iteradores.

También creo que sus ejemplos están desactivados, especialmente su copia de archivos: sí, la variante del iterador es una gran mejora sobre el código de 1975. Reduce un ciclo con una condición de interrupción complicada hasta una declaración. Lo que realmente está teniendo problema aquí es solo la sintaxis. Bueno, discúlpeme: estamos hablando de C++ aquí - por supuesto la sintaxis es fea. Y sí, usar rangos aquí es una mejora, pero solo sintácticamente.

También creo que la implementación de Andrei find está apagada. Lo que realmente define allí es la operación DropUntil (nombrar es difícil) de LINQ. La operación find realmente debería devolver uno o cero elementos (¡o un iterador!). Evitar los iteradores aquí no es útil en mi opinión, ya que es posible que deseemos modificar el valor directamente en lugar de copiarlo. Devolver un rango de un elemento aquí solo agrega sobrecarga sin un beneficio. Hacerlo de la manera de Andrei es malo porque entonces el nombre del método es simplemente incorrecto y engañoso.

Dicho esto, esencialmente estoy de acuerdo con Andrei en casi todos los puntos. Los iteradores, aunque son mi concepto favorito de la informática, son ciertamente una gran carga sintáctica y muchos rangos (especialmente generadores infinitos) pueden (y deben) implementarse cómodamente sin ellos.

Answer 2

Estoy de acuerdo con él en que los iteradores son en su mayoría inferiores a los rangos, y no sé si 'algo mejor' será recogido.

"Lo bueno es enemigo de lo mejor" está muy en juego aquí, como suele ser. Los iteradores son útiles y están firmemente arraigados, por lo que es difícil saber si algo mejor, como los rangos, puede suplantarlos en un tiempo razonable.

Answer 3

Creo que los implementadores de C++ tendrán sus manos llenas produciendo soporte de trabajo completo para C++ 0x, sin implementar nuevos paradigmas no estándar.

Answer 4

1. veces
2. Probablemente
3. No es probable, al menos no por muchos años

Answer 5

Creo que deberíamos usar rangos próximos a los iteradores, es decir, deberíamos elegir la forma de evolución, no de revolución.

Answer 6

C++ 0x ya está haciendo los primeros pasos:

• referencias rvalue resolver algunos problemas con el tratamiento de contenedores como rangos
• rangos se han añadido a la biblioteca núcleo, incluidos los conceptos de rango

La transición a rangos sin perder ninguna funcionalidad de iterador (piense en todas las combinaciones de categorías de iterador, const-ness y rvalue-ness) es difícil, especialmente si trata de factorizar los rangos infinito y mutable.

Answer 7

1. La mayoría de nosotros hace un uso simple de ellos en lo que se han convertido en expresiones idiomáticas bien conocidas, como en bucles para iterar a través de un std :: vector. Un desarrollador lo lee y sabe lo que está pasando. En nuestra vida de codificación diaria, los iteradores no son buenos o malos, simplemente son "lo que hace el trabajo".
2. Probablemente, sí.
3. No lo creo.

Answer 8

Andrei a veces puede ser un poco provocativo. Los iteradores son un concepto razonable, y bastante fundamentales en el sentido de que los bits sí lo son. Pero al igual que la mayoría de los bits en C++ no son bools, sino que forman parte de tipos más grandes, la mayoría de los iteradores deben tratarse en un nivel alto. Andrei tiene razón en que el nivel adecuado para hacerlo es el objeto rango. Pero no todos los rangos están adecuadamente expuestos como rangos de iteradores, como lo muestra istream_iterator sentinel. Eso es solo un truco para crear un iterador final artificial. Sin embargo, no creo que sus ideas sean recogidas por implementaciones. C++ 1x será tan relevante como C99.

Answer 9

El único argumento que puedo ver en esa presentación es la incapacidad de definir rangos, y la propuesta "Range for statement" de C++ 0x parece eliminar ese problema hasta cierto punto de todos modos. tal vez no debería ser un argumento sobre si los iteradores deberían/​​no deberían ser utilizados en absoluto, pero ¿para qué situaciones deberían/​​no deberían usarse?

Answer 10

Como cualquier API o función, si se usa incorrectamente puede crear muchos problemas de identificación difíciles. Los iteradores se han utilizado en muchos proyectos, pero siempre manteniendo la atención necesaria según sus características. Su uso debe ir precedido de una buena comprensión de sus limitaciones. Los iteradores pueden ser muy útiles si el usuario lo usa correctamente.Este
preguntas están relacionadas:
Is there any way to check if an iterator is valid?
Should I prefer iterators over const_iterators?

Answer 11

estoy de acuerdo tanto con Andrei y Konrad y yo :-)

El concepto más fundamental no es una interfaz de un iterador y que es bastante obvio en cualquier trabajo que alguien haga hoy (que tiene que ver con biblioteca cruzada, lenguaje cruzado, compilador cruzado, sistema operativo cruzado, plataforma cruzada, nombre cruzado :-)

Ni iterador ni rango (aparte de la fuente -lev el use) ofrece algo más que un puntero limpio y simple, no intrusivo o intrusivo, no compartido o compartido, no único o único. Limpiar el puntero a los datos mecanografiados simplemente se pone universal y puede hacer que los datos sean mutables o inmutables y muchas otras cosas. Toda la interfaz es solo otro nivel de direccionamiento indirecto a la vez que sigue siendo amigable con la máquina y el compilador de todo tipo, además de mucho más segura, relegando los iteradores y el uso del rango a un detalle de implementación.

Hasta ese punto, IEnumerable y IQueryable hacen la mitad de 'lo correcto' TM pero son claramente inferiores en sus conceptos de iteración y mucho más que lo que puede hacer con STL, retener el control y así sucesivamente (pero otoh, tienen mejores metadatos y, por lo tanto, un modelo mejor y más limpio). Siendo un punto con las interfaces puede construir cualquier abstracción que desee y satisfaga, probablemente contraversial pero esencialmente no obvia: óptimo, y representación y código de datos neutrales en tiempo de ejecución o en tiempo de compilación (diablos esencial para algoritmos y compiladores y máquinas virtuales y lo que no) .

Incluso es posible optimizarlo para sistemas 'dinámicos'/componentes hasta la alineación 'en tiempo de ejecución' (tornillo HotSpot VM :-) .. Hasta ese punto, el avance a 1975 es mínimo como lo evidencia una enorme industria de interoperabilidad carga de trabajo (está donde sea que mire, incluyendo este sitio, su uso de tecnología patentada y abierta, etc., en idealismo informático, bueno, este tipo de 'trabajo' de interfaz no debería existir si) ..

Answer 12

No es Andrei tratando de hacer un marketing oculto para el lenguaje D (actualmente está trabajando con él) ...?

Andrei afirma que los contenedores están bien, pero los iteradores son feos, no intuitivos, propensos a errores y peligrosos, difíciles de implementar (bueno, este último parece ser bastante cierto ...) Y qué tenemos en C++ ... punteros? ¿No son feos /.../ peligrosos? Pero felizmente los abrazamos y vivimos con ellos.

¿Cuál es más intuitiva para escribir:

for(auto i=foo.begin();i!=foo.end();++i) 
    bar(*i); 

o

for (auto r=foo.all(); !foo.empty(); foo.popFront()) 
     bar(r.front()); 

Iteradores concepto se puede complementar con rangos y otras ideas, pero creo que ellos tienen su lugar y no se ser reemplazado

Answer 13

1. No, no están nada mal, de hecho son una idea muy inteligente. Sin embargo, no son ideales y hay espacio para mejoras en el concepto de iterador.

2. Resuelve el número de problemas de la vida real con iteradores. Por ejemplo, es tedioso (también propenso a errores) en muchos casos consultar dos objetos separados, iteradores, desde un solo contenedor y luego pasarlos como dos objetos separados a un algoritmo. ¿Por qué no pasar un solo objeto? Incluso std::pair<iterator, iterator> crearía un rango crudo que es más fácil de manipular: un objeto, no dos. Además, es una buena idea considerar a range is an iterator.De hecho, eso es lo que sugiere Andrei. Por cierto, algunos de estos problemas ya han sido resueltos por Boost.Range.

3. Esperaría que sucediera, pero no será una revolución, sino una evolución.