tipos - C++ incrustado: ¿para usar excepciones o no?
try catch en c (4)
Me doy cuenta de que esto puede ser subjetivo, por lo que haré una pregunta concreta, pero primero, antecedentes:
Siempre he sido un ingeniero de software incrustado, pero generalmente en la Capa 3 o 2 de la pila OSI. No soy realmente un tipo de hardware. En general siempre he hecho productos de telecomunicaciones, generalmente teléfonos de mano / teléfonos celulares, lo que generalmente significa algo así como un procesador ARM 7.
Ahora me encuentro en un mundo embebido más genérico, en una pequeña empresa emergente, donde podría pasar a procesadores "no tan potentes" (está el bit subjetivo). No puedo predecir cuál.
He leído bastante sobre el debate sobre el manejo de excepciones en C ++ en sistemas integrados y no hay una respuesta clara. Hay algunas pequeñas preocupaciones sobre la portabilidad y algunas sobre el tiempo de ejecución, pero en su mayoría parece reducirse al tamaño del código (¿o estoy leyendo los debates equivocados?).
Ahora tengo que tomar la decisión de usar o renunciar al manejo de excepciones, para toda la empresa, para siempre (se trata de algo muy básico).
Eso puede sonar a "¿cuánto tiempo dura un trozo de cuerda?", Pero alguien podría responder "si su cuerda es un 8051, entonces no. Si, OTOH, es ...".
¿De qué manera salta? ¿Súper seguro y pierde una buena característica o código excepcional y tal vez se encuentre con problemas más adelante?
Diría que use excepciones adecuadamente si el entorno de tiempo de ejecución las admite. Las excepciones para manejar condiciones extraordinarias están bien, y pueden causar una sobrecarga pequeña dependiendo de la implementación. Algunos entornos no los admiten, especialmente en el mundo integrado. Si los prohíbe, tenga cuidado de explicar por qué. Una vez tuve un chico que, cuando le dijeron que no usara excepciones, hizo una división por cero en su lugar. No es exactamente lo que teníamos en mente.
El mayor problema con las excepciones: no tienen un tiempo de ejecución predecible. Por lo tanto, no son adecuados para aplicaciones duras en tiempo real (y supongo que la mayoría de las aplicaciones incrustadas no entran en esta categoría).
El segundo es (posible) aumentar el tamaño del binario.
Le propondría que leyera el Informe técnico sobre el rendimiento de C ++ que aborda específicamente los temas que le interesan: utilizar C ++ en sistemas integrados (incluidos los sistemas duros en tiempo real) y cómo se implementa generalmente el manejo de excepciones y qué sobrecarga tiene.
En términos de rendimiento, entiendo que las excepciones realmente reducen el tamaño y aumentan el rendimiento de las rutas de ejecución de código normales , pero hacen que las rutas excepcionales / de error sean más caras. (a menudo mucho más caro).
Entonces, si su única preocupación es el rendimiento, le diría que no se preocupe más tarde. Si la CPU de hoy puede manejarlo, mañana también lo hará.
Sin embargo . En mi opinión, las excepciones son una de esas características que requieren que los programadores sean más inteligentes todo el tiempo de lo que razonablemente se espera que sean los programadores. Entonces digo, si puedes mantenerte alejado del código basado en excepciones. Mantente alejado.
Eche un vistazo al Limpiador de Raymond Chen , más elegante y más difícil de reconocer . Él lo dice mejor que yo.
La elección de si usar excepciones o no debería realmente depender de si van a encajar bien con el dominio del problema de su programa o no.
He usado extensamente las excepciones de C ++, tanto en la adaptación al antiguo código C como en algún código más nuevo. (SUGERENCIA: No intente volver a ajustar el código C de 20 años que se escribió en un entorno con poca memoria con todo tipo de excepciones inconsistentes. Es solo una pesadilla).
Si su problema es uno que se presta para manejar todos los errores en un solo lugar (por ejemplo, un servidor TCP / IP de algún tipo, donde cada error se cumple con ''romper la conexión y volver a intentar''), entonces las excepciones son buenas - Puede lanzar una excepción en cualquier lugar y usted sabe dónde y cómo se manejará.
Si, por otro lado, su problema no se presta al manejo centralizado de errores, entonces las excepciones son un dolor REAL, porque tratar de descubrir dónde se maneja (o se debe) manejar algo puede convertirse fácilmente en una tarea de Sísifo. Y es realmente difícil ver el problema simplemente mirando el código. En su lugar, tiene que mirar los árboles de llamadas para una función determinada y ver dónde van a terminar las excepciones de esa función, para averiguar si tiene un problema.