2011-09-12 13 views
7

Al leer la revisión N3242 del borrador de C++ 11, parece que algunos componentes de las interfaces de la biblioteca estándar (especialmente el enhebrado y el bloqueo) dependen del manejo de excepciones.¿Hay una lista de interfaces de biblioteca estándar de C++ 11 que requieren excepciones habilitadas?

Dado que trabajo mucho con las excepciones deshabilitado, me pregunto qué componentes/características de la biblioteca serán (prácticamente o lógicamente) inutilizables sin el manejo de excepciones habilitado?

+0

Prácticamente, todas las características son utilizables, hasta que se produce una excepción real. Entonces tu programa falla. Si una función de biblioteca puede arrojar, esto se especifica en el estándar, por lo que en cierto modo hay una lista: el estándar en sí mismo. –

+0

@ n.m. parece que has leído mi publicación usando la definición incorrecta de "prácticamente": http://dictionary.reference.com/browse/practically. si no, hay una diferencia en la complejidad y localidad de cosas como 'std :: vector.at (size_t)' contra el enhebrado y el bloqueo de un programa/entorno. Después de haber implementado el enhebrado y el bloqueo de bibliotecas, puedo decirte que puedes defenderte contra el anterior de manera fácil y predecible. (cont) – justin

+0

(cont) defenderse de este último es mucho más complejo. cuando las cosas van mal, una excepción no controlada no es una solución (para algunos de nosotros). No puedo ignorar estos errores :) por lo tanto, no puedo confiar en las implementaciones de enhebrado y bloqueo de la biblioteca porque la única defensa ofrecida por la biblioteca son las excepciones. En conclusión, las interfaces de enhebrado y bloqueo no son una buena opción para los programas donde las excepciones están deshabilitadas. Espero que ayude. – justin

Respuesta

1

Esta pregunta tiene más de un mes de antigüedad y no ha recibido respuesta.

Proporciono una respuesta que se puede considerar una wiki de la comunidad, agregue a ella según sea necesario.

  • std::threadSección 30.2.2. Transitivo. Abstracción implementada mediante implementaciones nativas.

  • std::mutex, std::recursive_mutex, std::timed_mutex, std::recursive_timed_mutex. Sección 30.4.1, Intransitivo si proporciona su propio bloqueo libre de excepción (a través de BasicLockable, Lockable, TimedLockable). Abstracción implementada mediante implementaciones nativas.

  • std::condition_variableSección 30.5. Transitivo. Abstracción implementada mediante implementaciones nativas.

nota: Habrá más.

4

En primer lugar (solo como recordatorio), la desactivación de excepciones y RTTI son extensiones específicas del compilador que el estándar no tiene en cuenta.

Desde la Biblioteca estándar es asociada por lo general para el compilador, que puede ser que su aplicación de la biblioteca estándar ha sido diseñado específicamente para hacer frente a esto (y, en particular, para hacer frente a new regresan punteros nulos vez de aumentar std::bad_alloc).

Por lo tanto, lo que usted pide no es sensible. Consulte la documentación de su propia biblioteca para obtener una lista completa.

Dicho esto, el estándar garantiza que nunca se lanzarán varias operaciones. No sé de ninguna operación que trague excepciones, supongo que la mayoría de ellos son realmente seguros de usar tal como están.

Por ejemplo, todos los algoritmos deben ser seguros.

Todavía, una vez más, solo puedo recomendar leer la documentación de su implementación.

+0

hay variantes 'nuevas' comunes con el propósito de evitar 'bad_alloc'. 'nothrow_t' es la forma integrada que proporciona la biblioteca, otros (incluidos los asignadores definidos por el usuario) pueden ser definidos por el usuario mediante la colocación nueva. para las colecciones, se puede especificar un asignador que no arroje: 'std :: vector >' y luego la interfaz del vector se puede usar en gran medida siempre que cumpla con las reglas. (cont) – justin

+0

(cont) hay programas complejos de C++ de alta calidad que no se basan en excepciones. su publicación tiene méritos (+1), pero creo que se pueden hacer algunas generalizaciones * en este caso; de nuevo, mis ejemplos de enhebrado (inseguro), bloqueo (inseguro) y ahora vector (la interfaz puede usarse con seguridad si la vida de nadie depende de eso). – justin

+0

@Justin: No digo que no sea posible, solo digo que no es Estándar. Por ejemplo, aunque 'new (nothrow_t)' existe, un 'vector' podría no usarlo. Ahora, sé que algunas bibliotecas compilan sin excepciones, LLVM/Clang es una de ellas, por ejemplo. Sin embargo, también redefinieron la mayoría de las clases de utilidad. –

Cuestiones relacionadas