¿los pic´s aún no estan preparados para la programación orientada a objetos?

[PalitroqueZ]

He estado leyendo un excelente pequeño libro llamado Introducción a la OOP del grupo EIDOS

(bajar)

y haciendo analogias para ver si se puede aplicar a los uC PIC, tengo varias conclusiones: Que no se puede aplicar a nuestro queridos picitos (por lo menos de la serie 18 hacia atras).

Varias veces se ha escrito en el foro, el inconveniente que tienen los diferentes lenguajes de programación para micros en su deficiencia de manipular las variables, es verdad que también parte de la culpa es los pic´s, que por su baja velocidad de funcionamiento no hay mucho que hacer.

Según la "moderna" técnica (llamemosla así) de programar en estos tiempos, llamada Programación Orientada a Objetos existen 5 conceptos desarrollados que se aplican a los entornos de programación de ordenador:

Clase, Objeto, Herencia, Encapsulación y Polimorfismo.

dentro del concepto Encapsulación existe el principio de manejar las variables como privadas:

"...todos los datos de una clase son privados y se accede a ellos mediante métodos
públicos..."

(pg28)


es decir, que las variables globales no estan permitidas y estaría saliendose de la OOP.

Ahora bien aplicandolo a los micros, por palabras de Maunix sabemos lo que puede ocurrir si aplicamos inadecuadamente una variable local en un determinado programa.

Supongo que todo ello mejorará con el tiempo, a la vez que aumenten la velocidad de los
hardwares y la eficiencia de los compiladores.

[MGLSOFT]

Ya llegara!!
Al menos ya esta ocurriendo en los PLCs, porque no habremos de verlo en un PIC??
Si hoy ya puedes declarar en que pin quieres determinada funcionalidad, porque no a futuro (esperemos que proximo) utilizemos estas maravillas con POO...

[PalitroqueZ]

Hola Marcos.

Existe una aplicación llamada The Object-Oriented PIC que se consigue en http://www.oopic.com/

hay que probarlo a ver que tal es. (no se si existe una versión de prueba) 

[reiniertl]

hay varios problemas que impiden que la POO se utilie en sistemas a microcontrolador, sobre todo los de 8 bits. Entre ellas está la organización y arquitectura del uC

Pero también influyen la cantidad de memoria de programas y datos, y la complejidad y reusabilidad de código. No es algo simple de determinar, pero en la mayoría de los casos podremos pasarnos sin la POO en sistemas a microcontrolador.

Y en muchos casos usar la POO en lugar de ayudarnos podrá traernos muchos dolores de cabeza.

Saludos
Reinier

[RICHI777]

Hola gente aca va mi opinion...
Con respecto a la programacion orientada a objetos existen penalidades que en un micro de 8 bits, donde los recursos normalmente son escasos, son dificiles de llevar a cabo. A todo esto existe un "standart de facto" llamado EC++( Embeded C ++ ) donde ciertas caracteristicas del C++ son dejadas de lado y otras no, las cuales no son penalizadas en tamaño de código ni en espacio en RAM. Detallo algunas cosas:

• Clases. En este caso las clases son similares a las estructuras en C, solo se suman los metodos de las mismas, que son funciones, con lo cual este tipo de cosas las resuelve el compilador, no se aplican penaltys en tiempo de ejecucion ni en tamaño.
  
• Objetos. En este caso se utilizan operadores especiales, new y delete que no dejan de ser funciones especialecializadas o mejoradas del los conocidos malloc y free que normalmente existen implementaciones en cualquier compilador decente.
• Herencia, este concepto esta muy ligado al poliformismo, donde se debe mantener en RAM una tabla llamada VTABLE, virtual table donde los metodos ( funciones ) que son llamados son determinados en run-time. Normalmente en el standart EC++ solo soporta la herencia simple.
• Encapsulacion. Este item tambien es resuelta en tiempo de compilacion, un buen programa escrito en C la encapsulacion es intrisicamente soportada, con la definicion de variables y funciones declaradas como static.
• Poliformismo. Este punto ya lo explique anteriormente.
• Sobrecarga de operadores y funciones. Esta caracteristica tambien es resuelta por el compilador, en un compilador C ++ el nombre de las funciones declaradas son convertidas a texto aleatorio ( decolorado ) con lo cual el nombre de la funcion nunca se repite y el linkeo no falla.
• Constructores y destructores. Es similar al concepto en C a las funciones Init y DeInit, en este caso el compilador garantiza que la llamada a la funcion Init es siempre invocada y no olvidada por el programador.
• Operador This, esto si que es una penalidad ya que en el stack siempre se pushea un valor que representa un puntero a la funcion o objeto invocado.
  

Como

Para finalizar las cosas que son dejadas de lado son :

• Templates
• Manejo de excepciones

Como lei alguna vez, un buen programa escrito en C es orientado a obejtos.....
Saludos !

[PalitroqueZ]

... donde se debe mantener en RAM una tabla llamada VTABLE, ...

ese es otro problemita, el tener memoria RAM disponible, fijense que el problema en general es por la limitación del hardware, aún programando en c, hay que aplicar mañas para optimizar los programas en velocidad, trayendo como consecuencia, olvidarse de lo que es programar en c.

[PalitroqueZ]

Hola JCC40

es que precisamente, pensaba en la utopia de usar un mismo lenguaje de programación, con sus mismos estandares para aplicarlo donde de alcance de hacerlo, y no estar cmabiando el switche mentalmente cada vez que vamos a escribir un programa para un determinado dispositivo.

[RICHI777]

Coincido totalmente con vos PalitroqueZ !!!

[elmasvital]

Creo que se pierde muchisima potencia con la poo.. es un segundo nivel de abstracción y me parece que los pics están reservados para tareas más simples y directas. Con que se introduzcan instrucciones para hacerlos más optimizables para algun compliador de c yo creo que habremos ganado muchos enteros...

1 saludo.