librerias - vector stl c++ ejemplos

Invalidación de iterador de último momento en C++ 11

Question

La publicación más popular en las reglas de invalidación de C ++ Iterator afirma que no está claro si los iteradores del final (es decir, los devueltos por end() , cend() , rend() y crend() ) se invalidan de acuerdo con mismas reglas que los iteradores normales, que apuntan a elementos en el contenedor. Estas reclamaciones, hechas para C ++ 2003 y 2011, se remiten a una publicación que discute las reglas de invalidación del iterador final , donde la respuesta aceptada sugiere que la norma de 2003 es ambigua al respecto. Esta conclusión se basa en un comentario en 23.1 / 10 (en el contexto de swap() ) que parece implicar que cuando la especificación no menciona explícitamente la invalidación de los iteradores pasados, se pueden invalidar.

Un comentario sobre la pregunta de esa publicación (por mike-seymour) sugiere que C ++ 11 es inequívoco sobre este asunto, en el caso de deque s. Mi pregunta es sobre todos los contenedores:

• En C ++ 11, ¿hay alguna operación de contenedor que pueda invalidar un iterador pasado-final y donde este comportamiento es ambiguo en la especificación del lenguaje?

Dicho de otra manera,

• ¿Puedo confiar en la validez de un iterador pasado-final después de realizar una operación de contenedor que no dice que puede invalidar los iteradores pasado-final?

Answer 1

Mi pregunta es sobre todos los contenedores:

• En C ++ 11, ¿hay alguna operación de contenedor que pueda invalidar un iterador pasado-final y donde este comportamiento es ambiguo en la especificación del lenguaje?

No estoy seguro de lo que quiere decir con "donde este comportamiento es ambiguo en la especificación del lenguaje", pero ciertamente hay operaciones que invalidan los operadores pasados ​​(como insertar en un std::vector o std::string ).

Dicho de otra manera,

• ¿Puedo confiar en la validez de un iterador pasado-final después de realizar una operación de contenedor que no dice que puede invalidar los iteradores pasado-final?

Puede confiar en el iterador del pasado como en cualquier otro iterador: cualquier operación que no invalide (potencialmente) los iteradores no los invalidará. Excepto por la posibilidad de que el estándar tenga un error, es decir, todas las operaciones donde no dice que invaliden (potencialmente) a los operadores.

Answer 2

Al menos en GCC, el iterador final se invalida para std :: map:

#include <set>
#include <stdlib.h>
#include <assert.h>
int main() {
  std::set<int> a;
  a.insert(1);
  std::set<int>::reverse_iterator rit(a.rbegin());
  ++rit;
  assert(rit==a.rend());
  a.erase(a.begin());
  assert(a.rend()==rit); // FAIL
}

Answer 3

Debería poder confiar en él si el estándar dice que la operación no invalidará los iteradores. Cualquier otra cosa debe ser tratada como un error en la implementación de la biblioteca estándar.