¿Cuál es el mal uso común de usar contenedores STL con iteradores?

Question

¿Cuál es el mal uso común de usar contenedores STL con iteradores?

Answer 1

Olvidar que los iteradores a menudo se invalidan si cambia el contenedor insertando o borrando miembros del contenedor.

Para muchas grandes consejos sobre el uso de STL I altamente recomiendan libro de Scott Meyers "STL eficaz" (sanitised Amazon link)

Answer 2

Post-incrementarse cuando pre-incrementación va a hacer.

Answer 3

La verificación del rango final debe estar utilizando! = Y no <, ya que no se garantiza el orden de los punteros.

Ejemplo:

for(it = list.begin(); it != list.end(); ++it) 
{ 
    // do stuff 
} 

Answer 4

Su uso sin necesidad de leer el libro "STL eficaz" por Scott Meyers. :) De Verdad. Esto hace que la mayoría de los bichos estúpidos desaparezcan.

Answer 5

Algunos otros:

• Conversión de un iterador inverso en un iterador de base sin recordar que el iterador ahora será uno de los elementos más allá de la que estaba señalando.

• Intentando usar algoritmos que requieren un iterador de acceso aleatorio con iteradores de cosas como conjuntos y mapas.

• recomienda modificar la clave de una entrada de mapa con un iterador no constante (esto sucede a construir sobre VS.Net, pero no lo hará con GCC)

Answer 6

continuación adecuada después de erase().

Suponiendo:

Container::iterator i = cont.begin(), iEnd = cont.end(); 

Por ejemplo en std::map, esto no es una buena idea:

for (; i != iEnd; ++i) { 
    if (i->second.eraseCondition()) { 
     cont.erase(i); 
    } 
} 

esto funcionaría:

for (; i != iEnd;) { 
    Container::iterator temp = i; 
    ++temp; 
    if (i->second.eraseCondition()) { 
     cont.erase(i); 
    } 
    i = temp; 
} 

Y esto también:

for (; i != iEnd;) { 
    if (i->second.eraseCondition()) { 
     cont.erase(i++); 
    } 
    else { 
     ++i; 
    } 
} 

Ha sido demasiadas veces realmente que he tenido que aplicar estas correcciones en algún código de producción :(

Answer 7

El uso de un auto_ptr dentro de un contenedor, por ejemplo,

list<auto_ptr<int> > foo; 

Afortunadamente, muchas implementaciones auto_ptr estos días están escritos para hacer que esto sea imposible.

Answer 8

Esto no es solo un problema con los contenedores STL: el contenedor modyfing al iterar sobre él casi siempre genera problemas.

Esta es una fuente muy común de errores en los juegos: la mayoría de los bucles de juego consisten en iterar sobre cada objeto del juego haciendo algo. Si esto algo agrega o borra elementos del contenedor de objetos del juego, seguramente habrá errores.

Solución: tenga dos contenedores, objectsToDelete y objectsToAdd, en el código del juego agregue objetos a esos contenedores y actualice el contenedor de objetos del juego solo después de iterar sobre él.

objetsToAdd puede establecerse para garantizar que no eliminaremos nada más de una vez.

objectsToDelete puede ser cola si se puede construir objetos sin agregarlo a juego contenedor de objetos, o puede ser alguna otra clase (ObjectCreateCommand?) Si el código asume esa instancia de objeto siempre se añade al juego de objetos contenedores directamente después de la creación (por ejemplo en constructor).

Answer 9

list<int> l1, l2; 
// ... 

for_each(l1.begin(), l2.end(), do_it());