2009-08-24 14 views
7

Para contenedores asociativos, ¿puede el operador ++ enviar un iterador más allá del final de una colección?¿Puede un iterador de mapa STL salirse de los límites mediante el incremento?

Ejemplo:

map<UINT32, UINT32> new_map; 
new_map[0] = 0; 
new_map[1] = 1; 

map<UINT32, UINT32> new_iter = new_map.begin(); 

++new_iter; 
++new_iter; 
++new_iter; 
++new_iter; 
++new_iter; 
++new_iter; 
++new_iter; 

Al final de esto, no new_iter == new_map.end(), o se terminan en el gran desconocido?

Nota: Sé que esto está mal y no es la manera de hacer las cosas. Estoy trabajando con algún código corporativo de la WTF.

+1

¿Lo compiló y comprobó si será new_map.end() al final? Probablemente la forma más fácil de responder a una pregunta como esta, si no estás seguro. – Goz

+9

@Goz: No, eso solo respondería a lo que está haciendo una implementación. – sbi

+3

Posible duplicado de [¿Qué sucede si incrementa un iterador que es igual al final del iterador de un contenedor STL] (https://stackoverflow.com/questions/1057724/what-happens-if-you-increment-anitrator) -hat-is-equal-to-the-end-iterator-of-a) – Raedwald

Respuesta

11

La condición previa para el operador ++ para un iterador hacia adelante es que el iterador es Dereferenceable. Esto implica que no puede haber pasado el final del mapa, por lo que su código proporciona un comportamiento indefinido. Esto se describe en la sección 24.1.3 del Estándar C++.

+0

24.2.3 de hecho para el iterador de entrada, 24.2.4 para la salida. – Ruslan

5

Como han señalado otros, incrementar el iterador final causa un comportamiento indefinido; sin embargo, vale la pena señalar que Visual Studio 2008 lanzará una aserción de depuración en tiempo de ejecución (debido a su checked iterators) si hace esto.

Cuestiones relacionadas