tomar - ¿Hay alguna razón para usar C en lugar de C++ para el desarrollo integrado?

tabla de temperatura corporal (29)

¿Ve alguna razón para seguir con C89 cuando se desarrolla para hardware muy limitado (4kb de RAM)?

Personalmente, cuando se trata de aplicaciones integradas (cuando digo embedded, no me refiero a winCE, iPhone, etc. dispositivos embebidos hinchados hoy). Me refiero a recursos limitados. Prefiero C, aunque también he trabajado bastante con C ++.

Por ejemplo, el dispositivo del que se trata tiene 4kb de RAM, bueno solo por eso no consideraría C ++. Claro, puede diseñar algo pequeño usando C ++ y limitar su uso en su aplicación como lo han sugerido otras publicaciones, pero C ++ "podría" potencialmente terminar complicando / hinchando su aplicación bajo las cubiertas.

¿Vas a vincular estáticamente? Es posible que desee comparar una aplicación ficticia estática usando c ++ vs c. Eso puede llevarlo a considerar C en su lugar. Por otro lado, si puede crear una aplicación C ++ dentro de los requisitos de memoria, vaya por ella.

En mi humilde opinión, en general, en las aplicaciones integradas me gusta saber todo lo que está sucediendo. ¿Quién está usando recursos de memoria / sistema, cuánto y por qué? ¿Cuándo los liberan?

Cuando desarrollo para un objetivo con X cantidad de recursos, CPU, memoria, etc. Trato de mantenerme en el lado inferior de usar esos recursos porque nunca se sabe qué requisitos futuros se presentarán, lo que hace que agregue más código al proyecto que se "supone" que es una pequeña aplicación simple pero termina haciéndose mucho más grande.

Pregunta

Tengo dos compiladores en mi hardware C ++ y C89

Estoy pensando en usar C ++ con clases pero sin polimorfismo (para evitar los vtables). Las principales razones por las que me gustaría usar C ++ son:

Prefiero usar funciones "en línea" en lugar de definiciones de macro.
Me gustaría usar espacios de nombres, ya que prefijo desordenar el código.
Veo que C ++ es un poco más seguro, principalmente debido a las plantillas y al detallado moldeado.
Me gustan mucho las funciones y los constructores sobrecargados (utilizados para la fundición automática).

¿Ve alguna razón para seguir con C89 cuando se desarrolla para hardware muy limitado (4kb de RAM)?

Conclusión

¡Gracias por tus respuestas, fueron realmente útiles!

Pensé en el tema y me quedaré con C principalmente porque:

Es más fácil predecir el código real en C y esto es realmente importante si solo tienes 4kb de ram.
Mi equipo consiste principalmente en desarrolladores de C, por lo que las funciones avanzadas de C ++ no se usarán con frecuencia.
Encontré una forma de incorporar funciones en mi compilador de C (C89).

Es difícil aceptar una respuesta ya que proporcionó tantas buenas respuestas. Desafortunadamente no puedo crear una wiki y aceptarla, así que elegiré una respuesta que me hizo pensar más.

Mi preferencia personal es C porque:
Sé lo que hace cada línea de código (y cuesta)
No conozco C ++ lo suficiente como para saber qué hace cada línea de código (y cuesta)

¿Por qué la gente dice esto? No sabe lo que hace cada línea de C a menos que compruebe la salida de asm. Lo mismo vale para C ++.

Por ejemplo, ¿qué ASM produce esta afirmación inocente?

a[i] = b[j] * c[k];

Parece bastante inocente, pero un compilador basado en gcc produce esta asm para un micro de 8 bits

CLRF 0x1f, ACCESS RLCF 0xfdb, W, ACCESS ANDLW 0xfe RLCF 0x1f, F, ACCESS MOVWF 0x1e, ACCESS MOVLW 0xf9 MOVF 0xfdb, W, ACCESS ADDWF 0x1e, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfa MOVF 0xfdb, W, ACCESS ADDWFC 0x1f, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0xfee, 0x1c NOP MOVFF 0xfef, 0x1d NOP MOVLW 0x1 CLRF 0x1b, ACCESS RLCF 0xfdb, W, ACCESS ANDLW 0xfe RLCF 0x1b, F, ACCESS MOVWF 0x1a, ACCESS MOVLW 0xfb MOVF 0xfdb, W, ACCESS ADDWF 0x1a, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfc MOVF 0xfdb, W, ACCESS ADDWFC 0x1b, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0xfee, 0x18 NOP MOVFF 0xfef, 0x19 NOP MOVFF 0x18, 0x8 NOP MOVFF 0x19, 0x9 NOP MOVFF 0x1c, 0xd NOP MOVFF 0x1d, 0xe NOP CALL 0x2142, 0 NOP MOVFF 0x6, 0x16 NOP MOVFF 0x7, 0x17 NOP CLRF 0x15, ACCESS RLCF 0xfdf, W, ACCESS ANDLW 0xfe RLCF 0x15, F, ACCESS MOVWF 0x14, ACCESS MOVLW 0xfd MOVF 0xfdb, W, ACCESS ADDWF 0x14, W, ACCESS MOVWF 0xfe9, ACCESS MOVLW 0xfe MOVF 0xfdb, W, ACCESS ADDWFC 0x15, W, ACCESS MOVWF 0xfea, ACCESS MOVFF 0x16, 0xfee NOP MOVFF 0x17, 0xfed NOP

El número de instrucciones producidas depende masivamente de:

Los tamaños de a, b y c.
si esos punteros se almacenan en la pila o son globales
si i, j y k están en la pila o son globales

Esto es especialmente cierto en el pequeño mundo integrado, donde los procesadores simplemente no están configurados para manejar C. Así que mi respuesta sería que C y C ++ son tan malos como el uno al otro, a menos que siempre examinen la salida de asm, en cuyo caso son tan buenos como el uno al otro.

Hugo

¿Cuánto ROM / FLASH tienes?

4kB de RAM todavía pueden significar que hay cientos de kilobytes de FLASH para almacenar el código real y los datos estáticos. La RAM en este tamaño tiende a ser solo para variables, y si se tiene cuidado con ellas, se puede incluir un programa bastante grande en términos de líneas de código en la memoria.

Sin embargo, C ++ tiende a dificultar la colocación de código y datos en FLASH, debido a las reglas de construcción en tiempo de ejecución para los objetos. En C, una estructura constante se puede poner fácilmente en la memoria FLASH y acceder a ella como un objeto constante de hardware. En C ++, un objeto constante requeriría que el compilador evalúe el constructor en tiempo de compilación, lo cual creo que va más allá de lo que puede hacer un compilador de C ++ (teóricamente, podrías hacerlo, pero es muy difícil hacerlo en la práctica) .

Entonces, en un tipo de ambiente de "RAM pequeña", "FLASH grande" iría con C cualquier día. Tenga en cuenta que una buena opción intermedia i C99 que tiene la mayoría de las características agradables de C ++ para el código no basado en clases.

Acabo de encontrar un ejemplo de cómo usar ISO C ++ para desarrollo incrustado, que podría ser interesante para alguien que toma la decisión cada vez que usa C ++ o C.

Fue proporcionado por Bjarne Stroustrup en su página web :

Para ver cómo se puede utilizar ISO C ++ para la programación de sistemas embebidos, consulte los estándares de codificación C ++ del vehículo aéreo JSF .

Algunos dicen que los compiladores C pueden generar códigos mucho más eficientes porque no tienen que soportar las características avanzadas de C ++ y, por lo tanto, pueden ser más agresivos en sus optimizaciones.

Por supuesto, en este caso es posible que desee poner a prueba los dos compiladores específicos.

C gana en portabilidad, porque es menos ambiguo en la especificación del lenguaje; por lo tanto, ofrece una portabilidad y flexibilidad mucho mejores a través de diferentes compiladores, etc. (menos dolores de cabeza).

Si no va a aprovechar las características de C ++ para satisfacer una necesidad, entonces vaya con C.

Como ingeniero de firmware / sistema integrado, puedo decirles algunas de las razones por las que C sigue siendo la opción n. ° 1 en comparación con C ++ y, sí, domino ambos.

1) Algunos objetivos que desarrollamos tienen 64kB de RAM para código y datos, por lo que debe asegurarse de que cada byte cuente, y sí, he tratado la optimización de código para ahorrar 4 bytes que me costó 2 horas, y eso es todo 2008.

2) Todas las funciones de la biblioteca C se revisan antes de que las dejemos en el código final, debido a la limitación de tamaño, por lo que preferimos que no se use divisor (sin divisor de hardware, por lo que se necesita una gran biblioteca), malloc (porque no tenemos ningún montón , toda la memoria se asigna desde el búfer de datos en un fragmento de 512 bytes y debe ser revisada por el código), u otra práctica orientada a objetos que conlleve penalizaciones grandes. Recuerde, cada función de la biblioteca que usa cuenta.

3) ¿Has oído hablar del término superposición? tienes tan poco espacio de código que a veces tienes que intercambiar cosas con otro conjunto de código. Si llama a una función de biblioteca, entonces la función de biblioteca debe ser residente. Si solo lo usa en una función de superposición, está desperdiciando mucho espacio confiando en demasiados métodos orientados a objetos. Por lo tanto, no asuma ninguna función de biblioteca C, y mucho menos C ++ para ser aceptada.

4) Casting e incluso empaque (donde la estructura de datos no alineada cruza el límite de palabras) son necesarios debido al diseño de hardware limitado (es decir, un motor ECC que está cableado de cierta manera) o para hacer frente a un error de hardware. No se puede asumir demasiado en forma implícita, entonces, ¿por qué orientarlo demasiado?

5) El peor de los casos: eliminar algunos de los métodos orientados a objetos obligará a los desarrolladores a pensar antes de usar recursos que puedan explotar (es decir, asignar 512 bytes en una pila en lugar de un búfer de datos) y evitar algunos de los posibles escenarios de peor caso no se prueban o eliminan la totalidad de la ruta del código.

6) Usamos mucha abstracción para mantener el hardware alejado del software y hacer que el código sea lo más portátil posible, y amigable con la simulación. El acceso al hardware debe estar envuelto en una macro o función en línea que se compila condicionalmente entre plataformas diferentes, el tipo de datos debe formarse como tamaño de byte en lugar de como objetivo específico, no se permite el uso directo del puntero (porque alguna plataforma asume que la E / S asignada a la memoria es lo mismo que la memoria de datos), etc.

Puedo pensar en más, pero entiendes la idea. Los tipos de firmware de nosotros tienen formación orientada a objetos, pero la tarea del sistema integrado puede ser tan orientada al hardware y de bajo nivel, que no es de alto nivel ni abstraible por naturaleza.

Por cierto, cada trabajo de firmware en el que he estado usa el control de fuente, no sé de dónde sacas esa idea.

-Algunos tipos de firmware de SanDisk.

Depende del compilador.

No todos los compiladores incorporados implementan todo C ++, e incluso si lo hacen, es posible que no sean buenos para evitar la saturación de código (que siempre es un riesgo con las plantillas). Pruébelo con algunos programas más pequeños, vea si tiene algún problema.

Pero dado un buen compilador, no, no hay razón para no usar C ++.

Dos razones para usar C sobre C ++:

Para muchos procesadores integrados, no existe un compilador de C ++, o tienes que pagar extra por ello.
Mi experiencia es que una proporción significativa de ingenieros de software integrados tienen poca o ninguna experiencia de C ++, ya sea por (1) o porque tiende a no enseñarse en grados de ingeniería electrónica, por lo que sería mejor seguir con lo que ellos saben

Además, la pregunta original y una serie de comentarios mencionan los 4 Kb de RAM . Para un procesador integrado típico, la cantidad de RAM (en su mayoría) no está relacionada con el tamaño del código, ya que el código está almacenado y se ejecuta desde, flash.

Ciertamente, la cantidad de espacio de almacenamiento de código es algo a tener en cuenta, pero a medida que aparecen procesadores nuevos y más espaciosos en el mercado, es un problema menor de lo que solía ser para todos, excepto para los proyectos más sensibles a los costos.

Sobre el uso de un subconjunto de C ++ para su uso con sistemas integrados: ahora existe un estándar MISRA C ++ , que puede valer la pena examinar.

EDITAR: Vea también esta pregunta , que condujo a un debate sobre C vs C ++ para sistemas integrados.

El Informe técnico sobre el rendimiento de C ++ es una gran guía para este tipo de cosas. ¡Tenga en cuenta que tiene una sección sobre problemas de programación incorporada!

Además, ++ sobre la mención de Embedded C ++ en las respuestas. El estándar no es 100% para mi gusto, pero es un buen punto de referencia a la hora de decidir qué partes de C ++ podrías descartar.

Al programar para plataformas pequeñas, desactivamos excepciones y RTTI, evitamos la herencia virtual y prestamos mucha atención a la cantidad de funciones virtuales que tenemos por ahí.

Sin embargo, su amigo es el mapa del enlazador: lo verifica con frecuencia, y detectará rápidamente las fuentes de código y la acumulación de memoria estática.

Después de eso, se aplican las consideraciones de uso de la memoria dinámica estándar: en un entorno tan restringido como el que usted menciona, es posible que no desee usar asignaciones dinámicas. Algunas veces puede salirse con la suya con grupos de memoria para pequeños allocos dinámicos, o asignación "basada en cuadros" donde preasigna un bloque y lo descarta todo más tarde.

El libro C ++ para Game Programmers tiene información relacionada con cuándo el tamaño del código aumentará en función de las características de C ++.

En general no. C ++ es un súper conjunto de C. Esto sería especialmente cierto para los proyectos nuevos.

Está en el camino correcto para evitar las construcciones de C ++ que pueden ser costosas en términos de tiempo de CPU y memoria de pie de página.

Tenga en cuenta que algunas cosas como el polimorfismo pueden ser muy valiosas: son esencialmente indicadores de función. Si encuentra que los necesita, úselos con prudencia.

Además, un buen manejo de excepciones (bien diseñado) puede hacer que su aplicación incorporada sea más confiable que una aplicación que maneja cosas con códigos de error tradicionales.

He escrito un código para la plataforma integrada ARM7 en IAR Workbench. Recomiendo confiar en las plantillas para optimizar la compilación y la predicción de ruta. Evita el lanzamiento dinámico como la peste. Use rasgos / políticas a su favor, tal como lo prescribe el libro de Andrei Alexandrescu, Modern C ++ design .

Lo sé, puede ser difícil de aprender, pero también estoy seguro de que su producto se beneficiará de este enfoque.

He oído que algunas personas prefieren C para el trabajo integrado debido a que es más simple y, por lo tanto, es más fácil predecir el código real que se generará.

Personalmente, creo que escribir C-style C ++ (usando plantillas para seguridad tipográfica) te daría muchas ventajas y no veo ninguna razón real para no hacerlo.

La única razón para preferir C IMHO sería si el compilador de C ++ para su plataforma no está en buena forma (errores, optimización deficiente, etc.).

La mente humana se ocupa de la complejidad evaluando tanto como sea posible, y luego decide en qué es importante enfocarse, y descarta o deprecia el resto. Este es el sustento detrás de la marca en Marketing, y en gran medida, íconos.

Para combatir esta tendencia, prefiero C a C ++, porque te obliga a pensar sobre tu código, y cómo está interactuando con el hardware más de cerca, implacablemente cerca.

A partir de una larga experiencia, creo que C te obliga a encontrar mejores soluciones a los problemas, en parte, quitándote el camino y no forzándote a perder mucho tiempo satisfaciendo una restricción que el pensamiento del compilador-escritor fue una buena idea. , o averiguar qué está pasando "debajo de las sábanas".

En ese sentido, los lenguajes de bajo nivel como C te hacen dedicar mucho tiempo al hardware y construir buenos paquetes de estructura de datos / algoritmos, mientras que los lenguajes de alto nivel te hacen pasar mucho tiempo rascándote la cabeza preguntándote qué está pasando ahí. y por qué no puedes hacer algo perfectamente razonable en tu contexto y entorno específico. Vencer a tu compilador para que se someta (la tipificación fuerte es la peor ofensa) NO es un uso productivo del tiempo.

Probablemente encajé bien el molde del programador, me gusta el control. En mi opinión, eso no es un defecto de personalidad para un programador. El control es lo que nos pagan para hacer. Más específicamente, sin control. C le da mucho más control que C ++.

Mi elección generalmente viene determinada por la biblioteca de C que decidimos usar, que se selecciona en función de lo que el dispositivo debe hacer. Entonces, 9/10 veces ... termina siendo uclibc o newlib y C. El kernel que usamos es una gran influencia en esto también, o si estamos escribiendo nuestro propio kernel.

También es una opción de terreno común. La mayoría de los buenos programadores en C no tienen problemas para usar C ++ (aunque muchos se quejan durante todo el tiempo que lo usan) ... pero no he encontrado lo contrario para ser cierto (en mi experiencia).

En un proyecto en el que estamos trabajando (que involucra un kernel básico), la mayoría de las cosas se hacen en C, sin embargo, se implementó una pequeña pila de red en C ++, porque era más fácil y menos problemático implementar redes usando C ++.

El resultado final es que el dispositivo funcionará y pasará las pruebas de aceptación o no funcionará. Si puede implementar foo en xx stack y yy restricciones de montón utilizando el lenguaje z, avance, use lo que sea que lo haga más productivo.

Mi preferencia personal es C porque:

Sé lo que hace cada línea de código (y cuesta)
No conozco C ++ lo suficiente como para saber qué hace cada línea de código (y cuesta)

Sí, me siento cómodo con C ++, pero no lo sé tan bien como lo hago con la norma C.

Ahora, si puedes decir lo contrario, utiliza lo que sabes :) Si funciona, pasa las pruebas, etc. ¿cuál es el problema?

No veo ninguna razón para usar C en lugar de C ++. Lo que sea que puedas hacer en C, puedes hacerlo también en C ++. Si desea evitar los gastos generales de VMT, no use métodos virtuales ni polimorfismo.

Sin embargo, C ++ puede proporcionar algunos modismos muy útiles sin sobrecarga. Uno de mis favoritos es RAII. Las clases no son necesarias costosas en términos de memoria o rendimiento ...

No. Cualquiera de las características del lenguaje C ++ que podrían causar problemas (polimorfismo en tiempo de ejecución, RTTI, etc.) se puede evitar al realizar el desarrollo integrado. Existe una comunidad de desarrolladores de C ++ incrustados (recuerdo haber leído columnas de desarrolladores incrustados usando C ++ en el antiguo C / C ++ Users ''Journal), y no puedo imaginar que sean muy elocuentes si la elección es tan mala.

Para problemas de asignación de memoria, puedo recomendar el uso de Quantum Platform y su enfoque de máquina de estado, ya que asigna todo lo que necesitaría en el momento de la inicialización. También ayuda a aliviar los problemas de contención.

Este producto se ejecuta en C y C ++.

Para un objetivo con recursos muy limitados, como 4 KB de RAM, probaría las aguas con algunas muestras antes de comprometer un gran esfuerzo que no se pueda retrotraer fácilmente a una implementación pura de ANSI C.

El grupo de trabajo Embedded C ++ sí propuso un subconjunto estándar del lenguaje y un subconjunto estándar de la biblioteca estándar para ir con él. Perdí la pista de ese esfuerzo cuando el C User''s Journal murió, desafortunadamente. Parece que hay un artículo en Wikipedia , y que el committee todavía existe.

En un entorno incrustado, realmente debe tener cuidado con la asignación de memoria. Para hacer cumplir esa atención, es posible que necesite definir el operator new() global operator new() y sus amigos en algo que ni siquiera se puede vincular para que sepa que no se usa. Por otro lado, la ubicación new es probable que sea su amiga, cuando se usa juiciosamente junto con un esquema de asignación estable, seguro para subprocesos y latencia garantizada.

Las funciones en línea no causarán muchos problemas, a menos que sean lo suficientemente grandes como para haber sido verdaderas funciones en primer lugar. Por supuesto, las macros que reemplazaron tenían el mismo problema.

Las plantillas, también, pueden no causar un problema a menos que su instanciación se ejecute fuera de control. Para cualquier plantilla que utilice, audite el código generado (el mapa del enlace puede tener suficientes pistas) para asegurarse de que solo ocurrieron las instancias que pretendía usar.

Otro problema que puede surgir es la compatibilidad con su depurador. No es inusual que un depurador de hardware que de otro modo se pueda utilizar tenga un soporte muy limitado para interactuar con el código fuente original. Si efectivamente debe depurar en ensamblado, entonces el interesante cambio de nombre de C ++ puede agregar confusión adicional a la tarea.

RTTI, moldes dinámicos, herencia múltiple, polimorfismo pesado y excepciones vienen con una cierta cantidad de costo de tiempo de ejecución para su uso. Algunas de esas funciones tienen un nivel que cuesta sobre todo el programa si se usan, otras solo aumentan el peso de las clases que las necesitan. Conozca la diferencia y elija las funciones avanzadas sabiamente con pleno conocimiento de al menos un análisis de costo / beneficio superficial.

En un entorno incrustado pequeño, se vinculará directamente a un kernel en tiempo real o se ejecutará directamente en el hardware. De cualquier manera, deberá asegurarse de que su código de inicio de ejecución maneje las tareas de inicio específicas de C ++ correctamente. Esto puede ser tan simple como asegurarse de usar las opciones de enlazador correctas, pero como es común tener control directo sobre la fuente al punto de entrada de restablecimiento de encendido, es posible que deba auditar eso para asegurarse de que hace todo. Por ejemplo, en una plataforma ColdFire en la que trabajé, las herramientas dev se enviaron con un módulo CRT0.S que tenía los inicializadores C ++ presentes pero comentados. Si lo hubiera utilizado directamente desde la caja, me habría desconcertado los objetos globales cuyos constructores nunca se habían ejecutado en absoluto.

Además, en un entorno incrustado, a menudo es necesario inicializar los dispositivos de hardware antes de que puedan ser utilizados, y si no hay un sistema operativo ni un gestor de arranque, entonces es su código el que lo hace. Tendrá que recordar que los constructores de objetos globales se ejecutan antes de llamar a main() por lo que deberá modificar su CRT0.S local (o su equivalente) para que la inicialización del hardware se realice antes de que se llame a los propios constructores globales. Obviamente, la parte superior de main() es demasiado tarde.

Para un sistema limitado a 4K de RAM, utilizaría C, no C ++, solo para que pueda estar seguro de ver todo lo que está sucediendo. Lo que sucede con C ++ es que es muy fácil utilizar muchos más recursos (tanto CPU y memoria) que mirar el código. (Oh, crearé otro BlerfObject para hacer eso ... ¡gritos! ¡Fuera de memoria!)

Puede hacerlo en C ++, como ya se mencionó (sin RTTI, sin tablas, etc., etc.), pero pasará tanto tiempo asegurándose de que su uso de C ++ no se aleje de usted como lo haría con el equivalente en C .

Personalmente con 4kb de memoria, diría que no estás sacando mucho más provecho de C ++, así que solo escoge el que parece ser la mejor combinación de compilador / tiempo de ejecución para el trabajo, ya que el lenguaje probablemente no va a importar demasiado.

Tenga en cuenta que tampoco es todo sobre el lenguaje, ya que también importa la biblioteca. A menudo C libs tiene un tamaño mínimo ligeramente más pequeño, pero podría imaginarse que una lib de C ++ dirigida al desarrollo integrado se reduce, así que asegúrese de probar.

Recomiendo usar el compilador de C ++, pero limitar el uso de las características específicas de C ++. Puede programar como C en C ++ (el tiempo de ejecución de C se incluye al hacer C ++, aunque en la mayoría de las aplicaciones integradas no hace uso de la biblioteca estándar de todos modos).

Puede continuar y usar clases de C ++, etc., solo

Limite su uso de funciones virtuales (como ha dicho)
Limite su uso de plantillas
Para una plataforma incrustada, querrá anular el operador nuevo y / o utilizar la ubicación nueva para la asignación de memoria.

Respuesta diferente publicada en un aspecto diferente de la pregunta:

"malloc"

Some previous replies talk quite a bit about this. Why do you even think that call exists? For a truly small platform, malloc tends to be unavailable, or definitely optional. Implementing dynamic memory allocation tends to be meaningful when you get to have an RTOS in the bottom of your system -- but until then, it is purely dangerous.

You can get very far without it. Just think about all the old FORTRAN programs which did not even have a proper stack for local variables...

Solo quiero decir que no hay un sistema con recursos "ILIMITADOS". Todo en este mundo es limitado y TODAS las aplicaciones deben considerar el uso de recursos sin importar si es ASM, C, JAVA o JavaScript. Los dummies que asignan unos Mbs "solo para estar seguros" hacen que iPhone 7, Pixel y otros dispositivos sean extremadamente luggy. No importa si tiene 4kb o 40 Gb.

Pero desde otro lado para oponerse al desperdicio de recursos, es un tiempo que lleva ahorrar esos recursos. Si lleva 1 semana extra escribir algo simple en C para guardar algunos tics y algunos bytes en lugar de usar C ++ ya implementado, probado y distribuido. ¿Por qué molestarse? Es como comprar un concentrador usb. Sí, puedes hacerlo tú mismo, pero ¿va a ser mejor? ¿más confiable? más barato si cuentas tu tiempo?

Solo un pensamiento secundario: incluso la potencia de su tomacorriente no es ilimitada. Trata de investigar de dónde viene y lo verás en su mayor parte desde la quema de algo. La ley de la energía y el material sigue siendo válida: ningún material o energía aparece o desaparece, sino que se transforma.

Tienes en línea en C99. Tal vez te gusten los ctors, pero el negocio de hacer que los dtors sean correctos puede ser complicado. Si la única razón para no usar C es el espacio de nombres, me quedaría con C89. Esto se debe a que es posible que desee trasladarlo a una plataforma incrustada ligeramente diferente. Posteriormente, puede comenzar a escribir en C ++ con el mismo código. Pero tenga cuidado con lo siguiente, donde C ++ NO es un superconjunto de C. Sé que dijo que tiene un compilador C89, pero de todos modos compara C ++ con C99, ya que el primer elemento, por ejemplo, es verdadero para C desde K & R.

sizeof ''a'' > 1 en C, no en C ++. En C tiene matrices de longitud variable VLA. Ejemplo: func (int i) {int a [i] . En C tiene miembros de matriz de variables VAM. Ejemplo: struct {int b; int m [];}

Una buena razón y, a veces, la única razón es que aún no existe un compilador de C ++ para el sistema integrado específico. Este es el caso, por ejemplo, de los microcontroladores Microchip PIC . Son muy fáciles de escribir y tienen un compilador de C gratuito (en realidad, una pequeña variante de C), pero no hay ningún compilador de C ++ a la vista.

On such a limited system. Just go for Assembler. Gives you total control over every aspect, and gives no overhead.

Probably a lot faster too since a lot of embedded compilers are not the best optimizers (especially if one compares it to state of the art compilers like the ones we have for the desktop (intel, visual studio, etc))

"yeah yeah...but c is re-usable and...". On such a limited system, chances are you won''t re-use much of that code on a different system anyway. On the same system, assembler is just as re-usable.