Algunas características de C ++ tienen costos de tiempo de ejecución implícitos o pueden llevar a aumentos significativos en el tamaño del código. ¿Qué características debería considerar evitar al desarrollar un microcontrolador de recursos limitados? ¿Y por qué?
Esta es una pregunta cargada porque evitar una función de idioma puede llevarlo a compensarla. Por ejemplo, si evita usar clases de C ++ porque las "vtables" ocupan espacio, pero luego implementan sus propios POO utilizando enfoques de C que involucran estructuras estáticas que contienen punteros de función, ha recuperado las vtables.
Algunas funciones pueden tener una sobrecarga incluso si no las usa, como RTTI (información de tipo de tiempo de ejecución) y manejo de excepciones. Es posible que tu compilador tenga una manera de desactivar estos.
No usar la biblioteca estándar de C ++ y especialmente las plantillas (STL) es otra forma de ahorrar espacio, siempre que no sustituyas esto con otra cosa que esté hinchada, y realmente tengas una manera de eliminar la biblioteca (no la tengas). en el objetivo).
Tenga cuidado con la forma en que usa las plantillas. Siempre que sea posible, diseñe clases de plantillas para que sean funciones en línea muy ligeras, utilizando una implementación que no sea una plantilla (y por lo tanto no se expanda varias veces).
Un contenedor genérico o lo que sea, puede utilizar los enfoques de tipo void * y se envuelve con una plantilla delgada que proporciona el tipo de seguridad. La mayoría de las funciones en el contenedor son líneas en línea que realizan la conversión que desaparece en el código.
Creo que el comité de idiomas realmente tomó una postura oficial con respecto a los subconjuntos una vez, estaba fuertemente en contra de ellos.
Otros expertos creen que hay cierto valor para definir un subconjunto para entornos con recursos limitados, pero el lenguaje del subconjunto se llama a sí mismo "C ++ incrustado" es inútil.
La única disposición que el idioma oficial hace para el uso integrado es el "alojado" -vs- reglas de implementación "independientes", que permiten que un sistema integrado no admita una función "main ()" y su procesamiento asociado de comando. argumentos de línea.
Se debía evitar el uso de C ++ en la mayoría de los diseños de sistemas integrados del pasado. En particular, las partes de C ++ que crean clases y utilizan la sobrecarga de herencias, operadores y métodos, y el uso de muchas estructuras de puntero complejas para acceder a datos y / o códigos. Hay dos razones para esto, una de ellas es la RAM típicamente limitada disponible en microcontroladores integrados. El segundo problema es uno de rendimiento básico sin procesar si la CPU está manejando las características avanzadas de C ++.
Todavía hay muchas aplicaciones integradas, incluso hoy en día, que utilizan la variedad más barata de microcontroladores donde lo mismo es cierto. La tendencia en las últimas décadas de tener microcontroladores con todos sus FLASH (ROM) y RAM en un solo chip refuerza aún más este argumento.
En estos tiempos más modernos, ahora hay muchas soluciones integradas que utilizan procesadores de alto rendimiento que son componentes de tipo SOC. Estos a menudo admiten la conexión de grandes cantidades de memoria de tipo RAM dinámica DDR de gran ancho de banda para la ejecución de programas y el almacenamiento de datos. Estas partes también son compatibles con las partes de FLASH en serie de alta densidad para cargar el código del programa en la memoria RAM DDR para su ejecución, incluso con un sistema operativo como Linux o RTOS integrado. Estos sistemas integrados tienen recursos de rendimiento y memoria que rivalizan con el rendimiento típico de PC de tiempos anteriores. El uso de las características de C ++ en dicho sistema es ciertamente factible. Dicho esto, hay un tema completamente separado de rendimiento y confiabilidad predecibles del sistema embebido que entra en juego donde la complejidad de un Linux embebido y / o las estructuras de datos sobrecargados de una implementación de C ++ se cuestionan y en muchos casos se deben evitar.
Lea otras preguntas en las etiquetas microcontroller embedded c++