español - lista c++ stl

Los métodos iteradores de STL pueden lanzar una excepción

Question

Los destructores no pueden lanzar excepciones (por lo que el desenrollado de la pila puede completarse durante el manejo de excepciones), y debe desasignar los recursos asignados al objeto (por lo que no hay fuga de recursos). Un diseño para un objeto que contiene varios otros objetos (o se asigna a varios recursos) podría registrar los punteros en un contenedor STL. Por lo tanto, el destructor usaría los siguientes métodos relacionados con el iterador:

• begin() , end() para el contenedor
• operator++ para un iterador válido
• operator* o operator-> para un iterador válido

Pero para garantizar que el destructor no arroje excepciones y desasigne sus recursos, tendrá que confiar en que esos métodos nunca arrojarán excepciones.

¿Es seguro confiar en esos métodos que nunca lanzan excepciones? Es difícil imaginar una implementación práctica que arrojaría excepciones, ya que bajo el capó, un iterador STL es esencialmente un puntero. Pero, ¿el estándar C ++ requiere que esos métodos nunca arrojen excepciones? No he encontrado una declaración clara en el estándar de C ++.

Edición : El caso interesante es para C ++ 03 cuando desea tener un contenedor de punteros a recursos . Hay buenas razones para hacer esto; por ejemplo, si tienes recursos polimórficos. Como Björn Pollex señala en su respuesta, si usa un contenedor de recursos (como std::list< Resource > ) en lugar de un contenedor de punteros a recursos, el destructor del contenedor se encargará de la destrucción (desasignación) de los objetos de Resource para usted.

Answer 1

El destructor por lo tanto usaría los siguientes métodos relacionados con iteradores

No, no lo haría. El destructor de ese objeto solo llamaría al destructor del contenedor, lo que a su vez estaría garantizado para no lanzar una excepción.

Si usa RAII correctamente, casi nunca se encontrará con un escenario en el que deba liberar recursos de forma explícita. Esto podría lograrse teniendo el almacén de contenedores shared_ptr o unique_ptr , o usando algo como Boost.Pointer Container .

Answer 2

ningún constructor de copia u operador de asignación de un iterador devuelto lanza una excepción

Eso es de la norma C ++ 03. No creo que la norma vaya más allá de eso.

Por cierto son las 23.1.10

Answer 3

operador ++ para un iterador válido

El estándar C ++ (me refiero al borrador N3290) no otorga ninguna garantía para el incremento de operadores de iteradores.

Por ejemplo, los efectos de std::istreambuf_iterator::operator++ en la llamada a std::basic_streambuf::sbumpc . El sbumpc puede llamar a uflow que a su vez puede lanzar una excepción.

Answer 4

De acuerdo con http://www.tenouk.com/Module31.html estas operaciones (para ''*'' y ''->'' dependen también del tipo almacenado) no están disponibles para los contenedores STL.