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

https://stackoverflow.com/questions/812717

03-07-2019
|

Pregunta

Tengo dos compiladores en mi hardware C ++ y C89

Estoy pensando en usar C ++ con clases pero sin polimorfismo (para evitar 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 los prefijos saturan el código.
Veo que C ++ es un tipo de bit más seguro principalmente debido a las plantillas y el envío detallado.
Realmente me gustan las funciones y los constructores sobrecargados (utilizados para la conversión automática).

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

Conclusión

Gracias por sus respuestas, ¡fueron muy útiles!

Pensé en el tema y me atendré a 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 está formado principalmente por desarrolladores de C, por lo que las funciones avanzadas de C ++ no se usarán con frecuencia.
He encontrado una manera de integrar funciones en mi compilador de C (C89).

Es difícil aceptar una respuesta ya que ha proporcionado tantas respuestas buenas. Desafortunadamente no puedo crear un wiki y aceptarlo, así que elegiré una respuesta que me haga pensar más.

Solución

Dos razones para usar C sobre C ++:

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

Además, la pregunta original y varios comentarios, mencione los 4 Kb de RAM . Para un procesador incorporado típico, la cantidad de RAM no está relacionada (en su mayoría) con el tamaño del código, ya que el código se almacena 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 en el mercado nuevos procesadores con más capacidad, 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 uso con sistemas integrados: ahora hay un MISRA C ++ estándar, que puede valer la pena un vistazo.

EDITAR: vea también esta pregunta , que llevó a un debate sobre C vs C ++ para incrustar sistemas.

Otros consejos

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

El grupo de trabajo de Embedded C ++ propuso un subconjunto estándar del lenguaje y un subconjunto estándar de la biblioteca estándar para acompañarlo. Perdí la noción de ese esfuerzo cuando el Diario del usuario C murió, desafortunadamente. Parece que hay un artículo en Wikipedia , y que comité todavía existe.

En un entorno integrado, realmente debes tener cuidado con la asignación de memoria. Para hacer cumplir esa atención, es posible que deba definir el operador global new () y sus amigos a algo que ni siquiera se puede vincular para que sepa que no se usa. Por otra parte, es probable que la ubicación de new sea su amigo, cuando se usa con criterio junto con un esquema de asignación estable, seguro para subprocesos y con latencia garantizada.

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

Las plantillas, también, pueden no causar un problema a menos que su creación de instancias se ejecute de forma irregular. Para cualquier plantilla que use, audite su código generado (el mapa de enlaces puede tener suficientes pistas) para asegurarse de que solo ocurrieron las instancias que usted pretendía usar.

Otro problema que puede surgir es la compatibilidad con su depurador. No es inusual que un depurador de hardware de otro modo tenga un soporte muy limitado para la interacción con el código fuente original. Si efectivamente debe realizar una depuración en el ensamblaje, entonces la interesante manipulación de nombres de C ++ puede agregar confusión adicional a la tarea.

El RTTI, los modelos dinámicos, la herencia múltiple, el polimorfismo pesado y las excepciones vienen con cierta cantidad de costos de tiempo de ejecución para su uso. Algunas de las funciones de nivel que cuestan 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 conocimiento completo de al menos un análisis de costo / beneficio superficial.

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

Además, en un entorno integrado, a menudo es necesario inicializar los dispositivos de hardware antes de que puedan usarse, y si no hay un sistema operativo ni un cargador de arranque, es su código el que hace eso. Deberá recordar que los constructores para objetos globales se ejecutan antes main () , por lo que deberá modificar su CRT0.S local (o su equivalente) para obtener esa inicialización de hardware realizada antes se llama a los constructores globales. Obviamente, la parte superior de main () es demasiado tarde.

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 mientras se realiza el desarrollo integrado. Hay una comunidad de desarrolladores de C ++ incrustados (recuerdo haber leído columnas de desarrolladores incrustados que usan C ++ en el antiguo Diario de Usuarios de C / C ++), y no puedo imaginar que fueran muy explícitos si la elección fuera tan mala.

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 incrustados!

También, ++ en la mención de Embedded C ++ en las respuestas. El estándar no es del 100% para mis gustos, pero es una buena referencia al momento de decidir qué partes de C ++ puede eliminar.

Al programar para plataformas pequeñas, inhabilitamos las excepciones y RTTI, evitamos la herencia virtual y prestamos mucha atención al número de funciones virtuales que tenemos por ahí.

Sin embargo, tu amigo es el mapa del vinculador: compruébalo con frecuencia y verás que las fuentes de código y la memoria estática aumentan rápidamente.

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 utilizar asignaciones dinámicas en absoluto. A veces, puede salirse con los grupos de memoria para pequeñas asignaciones dinámicas, o " basado en marcos " asignación en la que se preasigna un bloque y se tira todo el asunto más tarde.

Recomiendo usar el compilador de C ++, pero limitando su 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).

Puedes seguir adelante y usar clases de C ++, etc., solo

Limita el uso de funciones virtuales (como has dicho)
Limita el uso de plantillas
Para una plataforma integrada, querrá anular el operador nuevo y / o usar la ubicación nueva para la asignación de memoria.

Como ingeniero de sistemas integrados / firmware, puedo decirles algunas de las razones por las que C sigue siendo la opción número 1 sobre C ++ y sí, tengo fluidez en ambos.

1) Algunos objetivos que desarrollamos tienen 64 KB de RAM tanto para el código como para los datos, por lo que debe asegurarse de que cada byte cuente, y sí, he lidiado con la optimización del código para ahorrar 4 bytes que me costaron 2 horas. y eso es en 2008.

2) Todas las funciones de la biblioteca C se revisan antes de dejarlas en el código final, debido a la limitación de tamaño, por lo que preferimos que las personas no usen la división (no se necesita divisor de hardware, por lo que se necesita una gran biblioteca), malloc (porque no tiene montón, toda la memoria se asigna desde el búfer de datos en un fragmento de 512 bytes y debe ser revisado por el código, u otra práctica orientada a objetos que conlleva una gran penalización. Recuerda, cada función de biblioteca que utilices 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ódigos. Si llama a una función de biblioteca, entonces la función de biblioteca debe ser residente. Si solo lo usas en una función de superposición, estás desperdiciando mucho espacio en muchos métodos orientados a objetos. Por lo tanto, no asuma ninguna función de la biblioteca C, y mucho menos que se acepte C ++.

4) La conversión e incluso el empaquetado (donde la estructura de datos no alineados cruza el límite de la palabra) son necesarios debido al diseño limitado del hardware (es decir, un motor ECC que está cableado de cierta manera) o para hacer frente a un error de hardware. No puede asumir demasiado de manera implícita, ¿por qué el objeto se orienta demasiado?

5) En 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 pueden explotar (es decir, asignar 512 bytes en una pila en lugar de hacerlo desde un búfer de datos), y evitar algunos de los peores potenciales Escenario de caso que no se probó ni eliminó la ruta completa del código en conjunto.

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

Se me ocurre más, pero entiendes la idea. Los tipos de firmware de los EE. UU. Tienen capacitació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 de naturaleza abstracta.

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

-algunos tipos de firmware de SanDisk.

Mi preferencia personal es C porque:


Sé lo que hace cada línea de código (y los costos)

No conozco a C ++ lo suficiente como para saber qué está haciendo (y sus costos) cada línea de código

¿Por qué la gente dice esto? Usted no sabe lo que hace cada línea de C a menos que verifique la salida de asm. Lo mismo ocurre con C ++.

Por ejemplo, qué asm produce esta declaración inocente:

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

Parece bastante inocente, pero un compilador basado en gcc produce este 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 están almacenados 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 incrustado, donde los procesadores simplemente no están configurados para manejar C. Así que mi respuesta sería que C y C ++ son tan malos entre sí, a menos que siempre examine la salida de asm, en en qué caso son tan buenos como los demás.

Hugo

He escuchado que algunas personas prefieren C para el trabajo integrado porque es más simple y, por lo tanto, más fácil de predecir el código real que se generará.

Personalmente, creo que escribir C ++ al estilo C (usar plantillas para la seguridad de tipos) le ofrecería muchas ventajas y no veo ninguna razón real para no hacerlo.

No veo ninguna razón para usar C en lugar de C ++. Cualquier cosa que puedas hacer en C, puedes hacerlo también en C ++. Si desea evitar los gastos generales de VMT, no utilice 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 necesariamente caras en términos de memoria o rendimiento ...

He escrito algún código para la paltforma integrada ARM7 en IAR Workbench. Recomiendo encarecidamente confiar en las plantillas para realizar la optimización en tiempo de compilación y la predicción de la ruta. Evita el reparto dinámico como la peste. Utilice los rasgos / políticas de la empresa para su ventaja, según lo prescrito en el libro de Andrei Alexandrescu, y, a continuación, haga clic en la dirección de la empresa, haga clic. X & oi = book_result & ct = result & resnum = 4 "rel =" noreferrer "> Diseño moderno de C ++ .

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

Una buena razón y, a veces, la única razón es que todavía no existe un compilador de C ++ para el sistema incorporado 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 variante de C), pero no hay un compilador de C ++ a la vista.

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

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

La mente humana se ocupa de la complejidad evaluando todo lo posible y luego decidiendo qué es lo importante en qué enfocar, y descartando o despreciando el resto. Este es todo el apuntalamiento detrás de la marca en Marketing, y en gran medida, los iconos.

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

Por una larga experiencia, creo que C te obliga a encontrar mejores soluciones a los problemas, en parte, al salir de tu camino y no forzarte a perder mucho tiempo para satisfacer una restricción que algunos compiladores y escritores pensaron que era una buena idea, o averiguar qué está pasando " debajo de las portadas " ;.

En ese sentido, los lenguajes de bajo nivel como C hacen que pases mucho tiempo centrado en el hardware y en la construcción de buenos paquetes de estructuras de datos / algoritmos, mientras que los lenguajes de alto nivel te hacen pasar mucho tiempo pensando en lo que está pasando allí, y por qué no puede hacer algo perfectamente razonable en su contexto y entorno específicos. Poner a su compilador en la sumisión (escribir con fuerza es el peor ofensor) NO es un uso productivo del tiempo.

Probablemente encajo bien en 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 por hacer. Más específicamente, el control impecable. C te da mucho más control que C ++.

Personalmente, con 4kb de memoria, diría que no está obteniendo mucho más kilometraje de C ++, así que simplemente elija la que parezca la mejor combinación de compilador / tiempo de ejecución para el trabajo, ya que el idioma probablemente no va a importar mucho. .

Tenga en cuenta que, de todos modos, tampoco se trata de lenguaje, ya que también importa la biblioteca. A menudo, las bibliotecas C libs tienen un tamaño mínimo un poco más pequeño, pero puedo imaginar que una biblioteca C ++ dirigida al desarrollo integrado se reduzca, así que asegúrese de probar.

Algunos dicen que los compiladores de C pueden generar código mucho más eficiente porque no tienen que admitir las funciones 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 con la portabilidad, porque es menos ambiguo en las especificaciones del idioma; por lo tanto, ofrece una mejor portabilidad y flexibilidad a través de diferentes compiladores, etc. (menos dolores de cabeza).

Si no va a aprovechar las funciones de C ++ para satisfacer una necesidad, vaya con C.

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

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

Por ejemplo, el dispositivo del que estás hablando tiene 4kb de RAM, bueno, por esa razón no consideraría C ++. Claro, puedes diseñar algo pequeño utilizando C ++ y limitar tu uso en tu aplicación, como han sugerido otras publicaciones, pero C ++ " podría " potencialmente terminar complicando / hinchando su aplicación debajo de las cubiertas.

¿Vas a enlazar estáticamente? Es posible que desee comparar una aplicación ficticia estática utilizando c ++ vs c. Eso puede llevarte a considerar C en su lugar. Por otro lado, si puede crear una aplicación C ++ dentro de sus requisitos de memoria, hágalo.

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

Al desarrollar para un objetivo con X cantidad de recursos, CPU, memoria, etc. Intento mantenerme en el lado inferior del uso de esos recursos porque nunca se sabe qué requisitos futuros se presentarán, por lo que le pido que agregue más código. el proyecto que se supuso " " " para ser una aplicación pequeña y simple, pero termina siendo mucho más grande.

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

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

En un proyecto en el que estamos trabajando (que involucra un núcleo desde cero), la mayoría de las cosas se hacen en C, sin embargo, una pequeña pila de red se implementó en C ++, porque fue 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 lo hará. Si puedes implementar foo en xx stack y yy heap con el lenguaje z, hazlo, usa cualquier cosa que te haga más productivo.

Mi preferencia personal es C porque:

Sé lo que hace cada línea de código (y los costos)
No conozco a C ++ lo suficiente como para saber qué está haciendo (y sus costos) cada línea de código

Sí, me siento cómodo con C ++, pero no lo sé tan bien como lo hago con el estándar C.

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

¿Cuánto ROM / FLASH tienes?

4kB de RAM todavía puede 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 tiene cuidado con esas, puede colocar 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, se puede colocar fácilmente una estructura constante 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 al constructor en tiempo de compilación, lo que creo que aún está más allá de lo que puede hacer un compilador de C ++ (teóricamente, puedes hacerlo, pero en la práctica es muy difícil) .

Entonces, en una " pequeña RAM " ;, " large FLASH " tipo de ambiente 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 buenas características de C ++ para código no basado en clases.

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

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

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

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

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

El libro C ++ para programadores de juegos contiene información relacionada con el tamaño del código se incrementará en función de las características de C ++.

Tienes inline en C99. Tal vez te gusten los ctors, pero el asunto de hacer los dtors bien puede ser complicado. Si la única razón restante para no usar C son los espacios de nombres, realmente me atendría a C89. Esto se debe a que es posible que desee trasladarlo a una plataforma integrada ligeramente diferente. Más tarde puede comenzar a escribir en C ++ en ese 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 hace esta comparación de C ++ con C99, ya que el primer elemento, por ejemplo, es válido para cualquier C desde K & amp; R.

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

Solo quiero decir que no hay ningún sistema con " ILIMITADO " recursos Todo en este mundo es limitado y CADA aplicación debe considerar el uso de recursos sin importar si es ASM, C, JAVA o JavaScript. Los dummies que asignan algunos Mbs " solo para estar seguros " hace que el iPhone 7, Pixel y otros dispositivos sean extremadamente blandos. No importa si tienes 4kb o 40 Gb.

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

Solo un pensamiento lateral: incluso el poder de su salida no es ilimitado. Intenta investigar de dónde viene y verás que se trata de quemar 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.

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 necesita en el momento de la inicialización. También ayuda a aliviar los problemas de contención.

Este producto se ejecuta tanto en C como en C ++.

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 expansión de código (que siempre es un riesgo para las plantillas). Pruébelo con algunos programas más pequeños, vea si tiene algún problema.

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

Acabo de encontrar un ejemplo de cómo usar ISO C ++ para el desarrollo integrado, 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 de inicio :

Para ver cómo se puede usar ISO C ++ para la programación seria de sistemas incorporados, consulte Normas de codificación C ++ para vehículos aéreos JSF .

Mensaje de respuesta diferente a un aspecto diferente de la pregunta:

" malloc "

Algunas respuestas anteriores hablan bastante sobre esto. ¿Por qué crees que existe esa llamada? Para una plataforma realmente pequeña, malloc tiende a no estar disponible, o definitivamente es opcional. La implementación de la asignación de memoria dinámica tiende a ser significativa cuando se tiene un RTOS en la parte inferior de su sistema, pero hasta entonces, es puramente peligroso.

Puedes llegar muy lejos sin él. Solo piense en todos los antiguos programas de FORTRAN que ni siquiera tenían una pila adecuada para las variables locales ...

Hay varios fabricantes de controladores diferentes en todo el mundo y cuando echa un vistazo a sus diseños y los conjuntos de instrucciones que deben usarse para la configuración pueden terminar en muchos problemas. La principal desventaja del lenguaje ensamblador es que depende de la máquina / arquitectura. Es realmente enorme pedirle a un desarrollador que cuente de memoria todas las instrucciones establecidas allí para realizar la codificación de diferentes controladores. Es por eso que C se hizo más popular en el desarrollo integrado porque C es lo suficientemente alto como para abstraer los algoritmos y las estructuras de datos de los detalles que dependen del hardware, lo que hace que el código fuente sea portátil en una amplia variedad de hardware objetivo, lenguaje independiente de la arquitectura y muy fácil de usar. Convertir y mantener el código. Pero sí vemos que algunos lenguajes de alto nivel (orientados a objetos) como C, C ++, Python, Java, etc. están evolucionando lo suficiente como para que queden bajo el radar del desarrollo de sistemas integrados.

En un sistema tan limitado. Sólo tienes que ir a ensamblador. Le da control total sobre todos los aspectos y no le otorga gastos generales.

Probablemente también sea mucho más rápido, ya que muchos compiladores integrados no son los mejores optimizadores (especialmente si uno lo compara con los compiladores de última generación como los que tenemos para el escritorio (Intel, Visual Studio, etc.))

" sí, sí ... pero c es reutilizable y ... " ;. En un sistema tan limitado, es probable que no reutilice mucho de ese código en un sistema diferente. En el mismo sistema, el ensamblador es igual de reutilizable.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow