¿Por qué no se pueden implementar los conceptos orientados a objetos en la programación integrada?

Podrías, pero ¿por qué? Dependería de si el modelo conceptual de su dispositivo involucraba dinámicamente un gran número de tipos de objetos que respondían a los mismos tipos de mensajes (o métodos u operaciones) como “copiar”, “gratis”, “esperar”, “enviar” , “recibir”, etc. e interactuaron entre sí con este tipo de cosas.

Casi de inmediato, tener todos estos objetos significa que necesitará un administrador de objetos, y ahora está comenzando a codificar un sistema operativo.

Una vez asignados dinámicamente, los recursos compartidos (que lo que describo anteriormente casi fomenta) podrían generar problemas de confiabilidad impredecibles cuando se enfrenta al agotamiento de los recursos, generalmente algo malo para este caso de uso.

OOP se utiliza en la programación integrada todo el tiempo, y no hay tiempo de ejecución adicional o costo de memoria para las características de OOP, en contra de las creencias populares.

Cuando escribes algo como:

clase A
{
público:
función vacía () {b = 5; }

privado:
int b;
};

Se compila con el mismo código de máquina que este:

estructura A
{
int b;
};

función vacía (A * esto)
{
esto-> b = 5;
}

(tenga en cuenta que este es un patrón muy común utilizado en C, sin OOP)

No hay nada inherentemente “costoso” sobre la POO. El compilador aplica todas las restricciones de acceso en tiempo de compilación. No hay costo de tiempo de ejecución por esa seguridad adicional. Ahora, ¿por qué no usarías eso en aplicaciones integradas?

Hay un ligero costo de memoria para las clases polimórficas (la tabla de métodos virtuales), pero eso es insignificante incluso para aplicaciones con mucha memoria limitada. Asciende a un puntero adicional en cada instancia, y unos pocos bytes por método virtual por tipo.

Lo que usa OOP NO implica: recolección de basura, uso de almacenamiento dinámico, biblioteca estándar grande.

Además, muchos sistemas integrados TIENEN un montón. Un montón realmente no es tan difícil de implementar, incluso cuando no tienes un sistema operativo. newlib es una biblioteca estándar C mínima que se usa comúnmente en sistemas embebidos, e implementa malloc (), siempre que defina una llamada al sistema sbrk (), lo cual es muy fácil.

Es posible, pero debe investigar un poco para descubrir las opciones.

Hay un paquete llamado Embedded Squeak en Smalltalk sobre Squeak Smalltalk. Es viejo. Está basado en una vieja VM Squeak (Versión 2.2), y fue diseñado para ejecutarse en Windows 95.

También hay versiones de Squeak para Android, que puede encontrar en el almacenamiento a largo plazo para Google Code Project Hosting y Raspberry Pi.

Fundamentalmente, podrían. Sin embargo, las consecuencias son extremas. La programación de sistemas integrados requiere un minimalismo cuidadoso. No se permiten bibliotecas o marcos gigantes. No hay recolección de basura.

Es cierto, podría hacer cosas pasando C a través de un compilador de C ++, pero hacer lo que sea necesario probablemente no haría feliz a ningún programador de OO.

Eso depende de lo que quiere decir con Orientado a Objetos, un punto que está lejos de ser acordado.

Muchos conceptos de OO requieren un montón para su implementación. Muchos sistemas integrados no pueden soportar un montón o no pueden permitir la indeterminación producida por la recolección de basura.