¿Hay casos del mundo real para C ++ sin excepciones? [cerrado]

¿En Cuándo usar C sobre C ++ y C ++ sobre C? hay una declaración wrt. para codificar excepciones de tamaño / C ++:

Jerry responde (entre otros puntos):

(...) tiende a ser más difícil producir ejecutables realmente pequeños con C ++. Para sistemas realmente pequeños, rara vez escribes mucho código de todos modos, y el extra (...)

a lo que pregunté por qué sería eso, a lo que Jerry respondió:

Lo principal es que C ++ incluye manejo de excepciones, que (al menos generalmente) agrega un mínimo al tamaño ejecutable. La mayoría de los compiladores le permitirán deshabilitar el manejo de excepciones, pero cuando lo haga, el resultado ya no será C ++. (...)

que realmente no dudo a nivel técnico del mundo real.

Por lo tanto, estoy interesado (por pura curiosidad) en escuchar ejemplos del mundo real en los que un proyecto eligió C ++ como lenguaje y luego eligió desactivar las excepciones. (No solo las excepciones de "no usar" en el código de usuario, sino deshabilitarlas en el compilador, para que no pueda lanzar o atrapar excepciones). ¿Por qué un proyecto elige hacerlo? (Todavía usando C ++ y no C, pero excepciones): ¿cuáles son / fueron los motivos (técnicos)?

Anexo: Para aquellos que deseen elaborar sus respuestas, sería bueno detallar cómo se manejan las implicaciones de las no excepciones:

• Las colecciones STL ( vector, ...) no funcionan correctamente (no se puede informar la falla de asignación)
• new no puede tirar
• Los constructores no pueden fallar

Casi todos los juegos de consola están en C ++ con la excepción desactivada, incluso hoy. De hecho, es la configuración predeterminada para los compiladores de C ++ destinados a esas consolas. A veces, no se garantiza que algunas funciones de C ++ funcionen correctamente en esos compiladores, como la herencia múltiple (por ejemplo, estoy pensando en un compilador predeterminado de consola muy conocido).

Además, otro ejemplo es el SDK de hardware Arduino que usa gcc sin excepción activada en C ++, y otras cosas como que no se proporciona STL .

Hay algunas razones técnicas, buenas o malas, lo que sea, no es mi consejo, sino razones que he escuchado:

1. La mayoría de las consolas son sistemas realmente integrados con memoria y tiempo de procesamiento limitados. Tal vez no sea tan cierto en las futuras consolas, pero las actuales siguen siendo bastante restrictivas en comparación con una PC. Algunas consolas portátiles son mucho más difíciles de programar que cualquier teléfono inteligente, por ejemplo, el NDS. La función de excepción agrega memoria y un poco de costo de velocidad, incluso si no la usa. Puede comprobarlo usted mismo, es cierto incluso en la PC.
2. Los videojuegos en la consola no pueden fallar. Tienen que ser probados de manera que eviten cualquier choque o cualquier callejón sin salida, cualquier espectáculo. Es por eso que los fabricantes de consolas solicitan que se revisen los juegos antes de su publicación. Eso también significa que la gestión de excepciones agrega un costo que no es realmente útil en el caso de juegos de consola. Es mejor en teléfonos inteligentes, por ejemplo, porque puede haber algunas formas de recuperación o agregar algún código para enviarle el problema por correo electrónico. Las plataformas cerradas como la mayoría de las consolas no permiten esto. Entonces, un sistema de excepción no es realmente necesario después de todo. "Solo tienes que hacer que funcione correctamente". ;)
3. La administración de excepciones, cuando no permite errores y fallas, significa que debe implementar una estrategia de administración de errores. Tal sistema puede ser lo suficientemente complejo como para hacer que alguien trabaje mucho tiempo para que sea útil. Los desarrolladores de juegos no tienen lujo para trabajar en funciones que se consideran útiles en los bloqueos ...
4. El compilador no lo permite (todavía). Si, pasa.

Creo que las excepciones pueden ser útiles incluso en los juegos, pero eso es cierto que en los juegos de consola no es realmente útil.

Actualizar:

Estoy agregando otro ejemplo sorprendente aquí: LLVM / CLang no usa excepción ni RTTI por las siguientes razones :

En un esfuerzo por reducir el código y el tamaño del ejecutable, LLVM no utiliza RTTI (por ejemplo, dynamic_cast <>) o excepciones. Estas dos características del lenguaje violan el principio general de C ++ de "solo paga por lo que usa", lo que provoca una hinchazón ejecutable incluso si nunca se usan excepciones en la base del código, o si RTTI nunca se usa para una clase. Debido a esto, los desactivamos globalmente en el código.

Dicho esto, LLVM hace un uso extensivo de una forma de RTTI enrollada a mano que usa plantillas como isa <>, cast <> y dyn_cast <>. Esta forma de RTTI es opcional y se puede agregar a cualquier clase. También es sustancialmente más eficiente que dynamic_cast <>.

CLang es bien conocido por su velocidad de compilación y errores explícitos, pero también es un compilador único que tiene un código realmente fácil de seguir.

Jerry dijo: ... el resultado ya no es C ++ , mientras que mi metáfora es que es claramente C ++, solo un dialecto ligeramente diferente porque los programas utilizan otras formas, convenciones y estilos escritos.

Aquí están mis razones principales para deshabilitarlas:

Compatibilidad binaria

Cruzar los límites del idioma y la traducción no está universalmente bien definido o indefinido. Si desea garantizar que su programa funcione dentro del dominio de comportamiento definido, deberá poner en cuarentena las excepciones en los puntos de salida del módulo.

Tamaño ejecutable

Aquí están los tamaños binarios de un programa libre de excepciones que escribí, creado sin y con excepciones habilitadas:

Sin excepciones:

• ejecutable + dependencias: 330
• ejecutable despojado final (versión de lanzamiento): 37

Con excepciones:

• ejecutable + dependencias: 380
• ejecutable despojado final (compilación de lanzamiento): 44

Recordatorio: es una colección de bibliotecas y programas que contienen cero lanzamientos / capturas. La bandera compilador hace permitir excepciones en la biblioteca estándar de C ++. Por lo tanto, el costo en el mundo real es más del 19% visto en este ejemplo.

Compilador: apple gcc4.2 + llvm. Tamaños en MB.

Velocidad

A pesar del término "excepciones de costo cero", todavía agregan algunos gastos generales incluso cuando nada arroja. En el caso anterior, es un programa crítico de rendimiento (procesamiento de señales, generación, presentación, conversiones, con grandes conjuntos de datos / señales, etc.). Las excepciones no son una característica necesaria en este diseño, mientras que el rendimiento es muy importante.

Corrección del programa

Parece una razón extraña ... Si lanzar no es una opción, debe escribir programas relativamente estrictos, correctos y bien probados para garantizar que su programa se ejecute correctamente, y que los clientes usen las interfaces correctamente (si me da un mal argumento o no lo hace) No verifique un código de error, entonces se merece UB). ¿El resultado? La calidad de la implementación mejora enormemente y los problemas se solucionan rápidamente.

Sencillez

Las implementaciones de manejo de excepciones a menudo no se mantienen actualizadas. También agregan mucha complejidad porque una implementación puede tener muchas, muchas, muchas secuencias de salida. Es más sencillo leer y mantener programas altamente complejos cuando utilizan un pequeño conjunto de estrategias de salida bien definidas, tipadas, que surgen y son manejadas por el cliente. En otros casos, las implementaciones pueden con el tiempo implementar más lanzamientos o sus dependencias pueden introducirlos. Los clientes no pueden defenderse fácil o adecuadamente contra todas estas salidas. Escribo y actualizo muchas bibliotecas, hay una evolución y una mejora frecuentes. Intentar mantener todo sincronizado con las secuencias de salida de excepción (en una base de código grande) no sería un buen uso del tiempo y probablemente agregaría mucho ruido y ruido. Debido a la mayor corrección del programa y más pruebas,

Historia / Código existente

En algunos casos, nunca se introdujeron por razones históricas. Una base de código existente no los usaba, cambiar los programas podría llevar muchos años y hacer que sea realmente feo de mantener debido a la superposición de convenciones e implementaciones.

Desventajas

Por supuesto, hay inconvenientes, los más importantes son: incompatibilidad (incluido binario) con otras bibliotecas, y el hecho de que tendrá que implementar una buena cantidad de programas para adaptarse a este modelo.

Google no aprueba las excepciones en su Guía de estilo de C ++ , principalmente por razones históricas:

A primera vista, los beneficios del uso de excepciones superan los costos, especialmente en proyectos nuevos. Sin embargo, para el código existente, la introducción de excepciones tiene implicaciones en todo el código dependiente. Si se pueden propagar excepciones más allá de un nuevo proyecto, también se vuelve problemático integrar el nuevo proyecto en el código existente sin excepciones. Debido a que la mayoría del código C ++ existente en Google no está preparado para hacer frente a las excepciones, es relativamente difícil adoptar un nuevo código que genere excepciones.

Dado que el código existente de Google no tolera las excepciones, los costos de usar excepciones son algo mayores que los costos en un nuevo proyecto. El proceso de conversión sería lento y propenso a errores. No creemos que las alternativas disponibles a las excepciones, como los códigos de error y las afirmaciones, introduzcan una carga significativa.

Nuestro consejo contra el uso de excepciones no se basa en razones filosóficas o morales, sino prácticas. Debido a que nos gustaría usar nuestros proyectos de código abierto en Google y es difícil hacerlo si esos proyectos usan excepciones, también debemos desaconsejar las excepciones en los proyectos de código abierto de Google. Las cosas probablemente serían diferentes si tuviéramos que volver a hacerlo desde cero.

Hay una excepción a esta regla (sin juego de palabras) para el código de Windows.

(Énfasis del editor)

Qt casi nunca usa excepciones. Los errores en Qt se indican con códigos y señales de error. La razón declarada oficialmente es:

Cuando se inició Qt, las excepciones no estaban disponibles para todos los compiladores que debían ser compatibles con Qt. Hoy estamos tratando de mantener las API consistentes, por lo que los módulos que tienen un historial de no usar excepciones generalmente no obtendrán código nuevo usando excepciones agregadas.

¿Por qué QT usa tan pocas excepciones?

Hoy, una crítica común de Qt es que su seguridad de excepción no está completa.

Symbian C ++ (usado en algunos teléfonos móviles Nokia) no usa excepciones, al menos no directamente, porque los compiladores de C ++ no las implementaron de manera confiable cuando Symbian se desarrolló por primera vez.

Yo / nunca / uso excepciones. Hay varias razones para esto, pero las dos razones principales son que nunca las he necesitado para producir código robusto y que reducen el rendimiento en tiempo de ejecución.

He trabajado en el código de producción que usa y deshabilita las excepciones: el código que permitía las excepciones era uniformemente peor. En algunos lugares, se utilizaron excepciones para el control de flujo genuino en lugar del manejo de errores, que es muy pesado, anti-rendimiento y difícil de depurar. En general, los problemas de depuración en el código lleno de excepciones fueron más difíciles que en el código libre de excepciones, en parte debido a la pila y las dificultades intrínsecas del mecanismo de excepción, pero mucho más que eso fue debido al código perezoso que se fomentó como resultado de tener disponible un manejo de excepciones.

No hay nada realmente malo con las excepciones en sí mismas / si no le importa el rendimiento / y no tiene tiempo para hacer algo correctamente: son una característica del lenguaje para el manejo de errores y un buen sustituto para un mecanismo adecuado de manejo de errores. Sin embargo, casi siempre hay / mejores / formas de manejar los errores, como con su propia lógica (es difícil de explicar, es casi de sentido común). Si no es su error, pero proviene de una biblioteca (por ejemplo, la biblioteca estándar), entonces debe respetar la elección de excepciones o tener algún bloqueo, pero siempre cuestionaría esa elección. Nunca he visto una situación en la que las excepciones fueran realmente la mejor solución.

Las afirmaciones son más depurables, los códigos de error son menos pesados ​​... entre los dos, si se usan correctamente, es más fácil leer, depurar y mantener el código, que es más rápido. Sus victorias en todo ...

En el estándar de codificación Joint Strike Fighter C ++ de Bjarne et. al., las excepciones están prohibidas debido a los duros requisitos en tiempo real de los aviones de combate.

JSF ++ es para aplicaciones en tiempo real y críticas para la seguridad (software de control de vuelo). Si un cálculo lleva demasiado tiempo, alguien puede morir. Por esa razón, tenemos que garantizar tiempos de respuesta, y no podemos, con el nivel actual de soporte de herramientas, hacerlo por excepciones. En ese contexto, ¡incluso la asignación gratuita de tiendas está prohibida! En realidad, las recomendaciones de JSF ++ para el manejo de errores simulan el uso de excepciones antes del día en que tenemos las herramientas para hacer las cosas bien, es decir, usar excepciones.

Citado de las preguntas frecuentes de C ++ de Bjarne .

Recuerde, C ++ probablemente ejecuta la más amplia variedad de software de todos los lenguajes ...

Es algo importante en el diseño de la biblioteca C ++. Muchas veces con una interfaz C es un poco desagradable lanzar una excepción de su biblioteca de terceros al cliente. Señale que si su biblioteca arroja, está eliminando un conjunto de clientes que lo habrían usado, dado que tenía una garantía de no tirar (por cualquier razón que el cliente tenga como restricción de excepciones).

Personalmente, he visto que se abusan de las excepciones cuando se le dice al equipo que "agregue una excepción" cuando sucede algo no tan terrible. Por supuesto, verá el error aquí: la excepción se arrojó en el código antes de que alguien descubriera qué hacer con él. Ese proyecto tuvo algunos accidentes, ya que estos lanzamientos profundos se formaban ocasionalmente.

Quizás a este respecto, vale la pena mencionar Embedded C ++ . Embedded C ++ es una variante de C ++ diseñada (obviamente suficiente) para sistemas embebidos. Básicamente es un subconjunto adecuado de C ++, con (entre otras cosas) plantillas, espacios de nombres y manejo de excepciones eliminado.

Debo agregar que si bien EC ++ causó un pequeño revuelo cuando era nuevo, parece que en su mayoría se han quedado bastante silenciosos. No estoy seguro de si las personas han perdido interés, o si su primer intento fue simplemente tan perfecto que nadie ha visto ninguna razón para meterse con eso durante una década más o menos.<closed captioning for the humor impaired>Yeah, right!</closed captioning>

Un buen ejemplo es la programación en modo kernel.

Puede usar C ++ allí para obtener un código más limpio, pero sin excepciones. No hay una biblioteca de tiempo de ejecución para ellos y el manejo de excepciones utiliza demasiada memoria de pila que es muy limitada en el núcleo (Experimenté con excepciones de C ++ en el núcleo de Windows NT y el lanzamiento y desenrollamiento de excepciones consume la mitad de la pila disponible, muy fácil de obtener desbordamiento de pila y bloquear todo el sistema).

Por lo general, define sus propios newy deleteoperadores. También placement newencontré referencias de valor de a y c ++ 11 bastante útiles . No se pueden utilizar STL u otras bibliotecas de modo de usuario de C ++ que se basan en excepciones.

Cuando intenta mantener baja la memoria ejecutable. Normalmente se realiza en sistemas integrados (o móviles). Para las aplicaciones de escritorio nunca es necesario, sin embargo, en los servidores, se puede considerar si desea la mayor cantidad de memoria RAM posible para el servidor web o para sql.