Sobrecarga de excepciones de C++

Sólo mis 2 centavos...

Consulto exclusivamente en sistemas embebidos, la mayoría de ellos duros en tiempo real y/o críticos de seguridad/vida. La mayoría de ellos se ejecutan en 256K de flash/ROM o menos - en otras palabras, estos son no sistemas de bus VME "similares a PC" con 1GB+ de RAM/flash y una CPU de 1GHz+. Son sistemas profundamente arraigados, algo limitados en recursos.

Yo diría que al menos el 75% de los productos que usan C++ deshabilitan excepciones en el compilador (es decir, código compilado con compilador conmutadores que deshabilitan excepciones). Siempre pregunto por qué. Lo creas o no, la respuesta más común NO es el tiempo de ejecución o la sobrecarga / costo de memoria.

Las respuestas suelen ser una mezcla de:

• "No estamos seguros de saber cómo escribir código seguro de excepción". Para ellos, comprobar los valores de retorno es más familiar, menos complejo, más seguro.
• " Suponiendo que solo lanzas una excepción en casos excepcionales, estas son situaciones en las que reiniciamos de todos modos [a través de su propio error crítico rutina de manejador] "
• Problemas de código heredado (como jalf había mencionado): están trabajando con código que comenzó hace muchos años cuando su compilador no soportaba excepciones o no las implementaba de manera correcta o eficiente

También, a menudo hay cierta incertidumbre/miedo nebuloso sobre los gastos generales, pero casi siempre no se cuantifica / no se filma, simplemente se arroja y se toma al pie de la letra. Puedo mostrarle informes / artículos que indican que la sobrecarga de las excepciones son 3%, 10% -15%, o ~30% - elija. La gente tiende a citar la figura que transmite su propio punto de vista. Casi siempre, el artículo está desactualizado, la plataforma / conjunto de herramientas es completamente diferente, etc. como dice Roddy, debes medirte en tu plataforma.

No defiendo necesariamente ninguna de estas posiciones, solo le estoy dando comentarios / explicaciones del mundo real que he escuchado de muchas empresas que trabajan con C++ en sistemas embebidos, ya que su pregunta es " ¿por qué tantos ¿los desarrolladores incrustados evitan excepciones?"

Creo que es principalmente FUD, en estos días.

Las excepciones tienen una pequeña sobrecarga en la entrada y salida de los bloques que crean objetos que tienen constructores/destructores, pero eso realmente no debería equivaler a una lata de frijoles en la mayoría de los casos.

Mida primero, Optimice segundo.

Sin embargo, lanzar una excepción suele ser más lento que devolver una bandera booleana, por lo que lanzar excepciones solo para eventos excepcionales.

En un caso, vi que el RTL estaba construyendo trazas de pila imprimibles completas a partir de tablas de símbolos cada vez que se lanzaba una excepción para un posible uso de depuración. Como se puede imaginar, esto no era una Cosa Buena. Esto fue hace unos años y la biblioteca de depuración se arregló apresuradamente cuando esto salió a la luz.

Pero, IMO, la fiabilidad que puede obtener del uso correcto de excepciones supera con creces la penalización de rendimiento menor. Úsalos, pero con cuidado.

Editar:

@jalf hace algo bueno y mi respuesta anterior estaba dirigida a la pregunta relacionada de por qué muchos desarrolladores embebidos en general siguen menospreciando las excepciones.

Pero, si el desarrollador de un SDK de plataforma en particular dice "no use excepciones", probablemente tendría que ir con eso. Tal vez hay problemas particulares con la implementación de excepciones en su biblioteca o compilador, o tal vez les preocupan las excepciones lanzadas en las devoluciones de llamada que causan problemas debido a la falta de excepción seguridad en su propio código.

Esta actitud hacia las excepciones no tiene nada que ver en absoluto con el rendimiento o el soporte del compilador, y todo tiene que ver con la idea de que las excepciones añaden complejidad al código.

Esta idea, por lo que puedo decir, es casi siempre un concepto erróneo, pero parece tener poderosos defensores por alguna razón inconcebible.

Una opinión contraria a los "gotos son malos" expuestos en las otras respuestas. Estoy haciendo este wiki de la comunidad porque sé que esta opinión contraria será incendiada.

Cualquier programador en tiempo real que valga la pena conoce este uso de goto. Es un mecanismo ampliamente utilizado y ampliamente aceptado para el manejo de errores. Muchos entornos de programación en tiempo real no implementan . Las excepciones son conceptualmente solo versiones restringidas de setjmp y longjmp. Entonces, ¿por qué proporcionar excepciones: cuando el mecanismo subyacente está prohibido?

Un entorno podría permitir excepciones si siempre se puede garantizar que todas las excepciones lanzadas se manejen localmente. La pregunta es, ¿por qué hacer esto? La única justificación es que los goto son siempre malvados. Bueno, no siempre son malvados.

El compilador moderno de C++ puede reducir el uso en tiempo de ejecución de la excepción a menos de un 3% de la sobrecarga. Aún así, si el programador extremo lo encuentra caro, entonces habrían recurrido a tales trucos sucios.

Vea aquí la página de Bjarne Strourstrup para, ¿Por qué usar excepciones ?

Puede referirse a http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions