Uso de C++ en sistemas embebidos.

[Agustin Bonelli]

Buenas a todos, 

Queria reunir opiniones respecto de porque en el ambito de sistemas embebidos se sigue prefiriendo el uso de C sobre C++ en general. En los ambitos en los que ustedes suelen trabajar, cuales son las principales razones (si las hay): Falta de soporte por parte de los toolchains? C++ es muy complicado? C ofrece mejor control? Hay mas programadores disponibles que sepan sobre ARM, arquitectura de micros y bajo nivel que solo saben C y no tanto C++?

Espero sus opiniones!

Saludos!

[Ing. Mirko Serra]

Sacando alguna excepción de algún micro raro o viejo donde no hay soporte, la principal razón es falta de experiencia de los programadores y la ley del menor esfuerzo.

Prácticamente todo código de C es válido en C++. Así que incluso (si se tiene miedo de rendimiento) se puede apelar a código C y mezclar, o un código de C++ que no sea tan orientado a objetos. O se lo puede ir migrando de a poco. El primer paso es cambiar de compilador e intentar compilar el código C puro con un compilador de C++.

Un amigo hizo parte de su código en un LPC1769 con FreeRTOS usando la (a veces desaconsejada) herencia múltiple y quedó sencillo, fácil de entender y funcionando muy bien.

C++ ofrece total control y los features nuevos son prácticamente costo cero si no se los usa. Pero hace falta obviamente conocer bien el lenguaje, por ejemplo, en embebidos donde se quiere velocidad en la memoria dinámica o casos donde se quiere cierto grado de determinismo, se puede sobrecargar el operador new para que dé memoria de un buffer estático (sin malloc).

Hay un buen libro en ese sentido creo que es Effective C++ de Scott Meyers. Da muchos tips de errores comunes cuando empieza (o cuando uno pasa de C a C++) que producen código ineficiente.

Saludos.

Ing. Mirko Serra.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

[martin ribelotta]

Me vino a la mente esto:
http://www.dansaks.com/talks/ESC-205.pdf

Cuando este con mas tiempo agrego mis experiencias en este aspecto.

El 1 de marzo de 2018, 14:16, Agustin Bonelli <agustin...@hotmail.com> escribió:

--

[Leonardo Urrego]

Personalmente he visto que entre mas alto es el nivel de abstracción
del lenguaje, mas código innecesario se genera, eso si, depende
también mucho del programador y del compilador, pero en general si
suele pasar eso . . .

>> embebidos32...@googlegroups.com. Para más opciones, visita el sitio

>> del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
>> ---
>> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
>> Grupos de Google.
>> Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes,

>> envía un correo electrónico a embebidos32...@googlegroups.com.

>> Para acceder a más opciones, visita https://groups.google.com/d/optout.
>
>

> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google
> Embebidos32. Para postear en este grupo, escribe un email a
> embeb...@googlegroups.com. Para des-suscribirte, envía un email a

> embebidos32...@googlegroups.com. Para más opciones, visita el sitio

> del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de
> Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes,

> envía un correo electrónico a embebidos32...@googlegroups.com.

> Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
Carlos Leonardo Urrego Laiton
Ing. Electrónico UD

[martin ribelotta]

Amplio entre lineas:

El 1 de marzo de 2018, 17:06, martin ribelotta <martinr...@gmail.com> escribió:

Me vino a la mente esto:
http://www.dansaks.com/talks/ESC-205.pdf

Cuando este con mas tiempo agrego mis experiencias en este aspecto.

El 1 de marzo de 2018, 14:16, Agustin Bonelli <agustin...@hotmail.com> escribió:

Buenas a todos, 

 

Queria reunir opiniones respecto de porque en el ambito de sistemas embebidos se sigue prefiriendo el uso de C sobre C++ en general. En los ambitos en los que ustedes suelen trabajar, cuales son las principales razones (si las hay): Falta de soporte por parte de los toolchains? C++ es muy complicado? C ofrece mejor control? Hay mas programadores disponibles que sepan sobre ARM, arquitectura de micros y bajo nivel que solo saben C y no tanto C++?

Para empezar, pongamos algunos puntos sobre la mesa:

 - C no es mas fácil de usar que C++, simplemente es lo que algunos aprendieron y cuesta aprender conceptos nuevos cuando hay que entregar para la semana que viene

 - C++ no es necesariamente mas pesado que C. De hecho, para las mismas tareas, C++ permite expresar cosas (basándonos en la metaprogramacion) mas livianas que C (en términos de ejecución final, ya que permite resolver la gran mayoría de las cosas en tiempo de compilación)

 - Salvo que tu arquitectura sea muy pedorra hay compiladores de C++ decentes en todos lados. E incluso así, se puede echar mano del CLANG+LLVM para convertir código de C++ a C al vuelo (y compilar con lo que queramos luego)

El punto principal creo yo, es que decir "se C" es mas fácil que decir "se C++". El primero podemos autoengañarnos bastante rápido y en la mayoría de los casos, no vamos a tener mucho problema en seguir engañados hasta que tengamos que lidiar con cosas realmente complicadas. En el segundo, es casi de inmediato que nos topamos con conceptos suficientemente profundos y abstractos como para borrar el autoengaño de "se algo" ni bien hacemos dos lineas de código serias.

En mi experiencia, un programador de bajo nivel puede manejar tanto C como C++ como cualquier cosa que compile a lenguaje de maquina de forma controlable (D, golang, rust, etc). Lo que pasa es que en determinado punto, nos encontramos con mucha gente que hace cosas "de expertos" sin conocer las bases ni de la programación ni de lo que esta programando. En ese punto, aprender cualquier lenguaje, paradigma o tecnología es salirse de su zona de confort, por mas que los beneficios sean superiores.

También, por el echo de que se puede hacer cualquier cosa en C (como en ensamblador) tanto como en C++ la desision pasa por varios otros puntos:

 - Velocidad de desarrollo

 - Mantenibilidad

 - Autodocumentacion

 - Existencia de herramientas ya hechas.

Por ultimo, no es que C++ se use poco en embebidos, todo Arduino esta escrito en C++ (por gente que no tenia ni pajolera idea de lo que era C++ ni las posibilidades que ofrecía, ni los problemas que generaba lo que se estaba haciendo), lo mismo mbed (este bastante mejor pensado y bastante mejor implementado)

También hay que contar el hecho de que los desarrolladores de librerías prefieren portabilidad antes que funcionalidad o simplicidad. Solo hay que ver lo asqueroso que son los compiladores de C++ para pic14 (y los compiladores de C también... para que nos vamos a engañar, pic14 es basura como arquitectura)

[Eric Pernia]

Yo creo que el tema es más de educación que tecnológico. 

En C++ se puede lograr el mismo rendimiento que en C. Y en ambos se puede incluir alguna función en assembler cuanddo estamos complicados con la performance de alguna función. Pasa por lo que sabe y le gusta a cada uno el aprovechar las cosas o pegarle a todo con el mismo martillo.

Habiendo dado clases tanto de programación muy básica de assembler, C, programación avanzada en C y POO para electrónica y automatización y control; y teniendo mucha relación con profesores y alumnos de carreras de sistemas y programación, resulta que depende todo del lado que se ven las cosas, en mi experiencia pasa esto:

Los alumnos de las carreras de electrónica detestan la abstracción de la POO, no quieren aprender a programar, si no los lenguajes que más puedan usar en un trabajo, y quieren saber que pasa con el bit en cada momento, disfrutan más las materias donde se ve toda la parte más física y de arquitectura que la programación abstracta. *

En el otro extremo tenemos los de las carreras de sistemas y programación quieren abstraerse completamente del hardware y trabajar en una máquina ideal que no quieren saber como funciona y le tienen asco a conectar cables, conocer la arquitectura a bajo nivel, pasan la única materia que ven de bajo nivel y arquitectura como un suplicio. *

* En ambos casos es en mayoría, no quiero generalizar.

Entonces pasa una especie de river-boca en el cual influyen sin querer los profesores que no se actualizan y siguen usando lo que saben y les funcionó...

Yo trato de que los alumnos lo vean como un todo y que cada uno elija donde le gusta más ubicarse en todo el abanico de posibilidades.

Abrazos,

Eric.

[carlos cabas]

Buenas noches.

Tal cual lo comenta Eric, en mi caso particular siendo electrónico, cuando he intentado programar POO para sistemas embebidos siento que pierdo en control de varias partes del código (es una sensación muy particular), por tal motivo me he mantenido en C en cuanto a sistemas embebidos se refiere.

Cuando es tema de software no tengo ningún inconveniente en escribir por ejemplo en C#.

Diría que es cuestión de enseñanza y de que parte de la ingeniería provengas, los ingenieros de sistemas manejan muy fácilmente el tema POO, en mi caso fue muy duro entender el concepto de clases sin que el subconsciente  lo relacionara con estructuras en C.

Cordialmente;

Carlos Cabas Meriño

Ingeniero Electrónico

Est. Automatización Industrial (UBA)

Técnico Profesional en Contabilidad y Finanzas

[Alejandro Celery]

El jueves, 1 de marzo de 2018, 15:17:39 (UTC-5), Leonardo Urrego escribió:

Personalmente he visto que entre mas alto es el nivel de abstracción
del lenguaje, mas código innecesario se genera, eso si, depende
también mucho del programador y del compilador, pero en general si
suele pasar eso . . .

Sí, bueno, mi tío Horacio decía "Vos podés tener un elefante en un bazar, solo lo tenés que llevar finito".

Me sumo a lo que dijo Mirko, en mi experiencia lo que hay es miedo a lo desconocido (en este caso a lo que vas a terminar cargando en el micro). Es mucho más fácil saber (o suponer en algunos casos) lo que va a hacer el compilador programando en C que en C++, para eso tenés que conocer algunos detalles del lenguaje.
Igualmente si le hacés
También me sumo a la recomendación del "Effective C++", solo aclaro que de "Effective" no tiene un pepino, la mayoría de los tips son del tipo "Ni se le ocurra programar en C++ si no sabe estas cosas".

Saludos!
 

[martin ribelotta]

El 2 de marzo de 2018, 0:02, carlos cabas <ing.car...@gmail.com> escribió:

Buenas noches.

Tal cual lo comenta Eric, en mi caso particular siendo electrónico, cuando he intentado programar POO para sistemas embebidos siento que pierdo en control de varias partes del código (es una sensación muy particular), por tal motivo me he mantenido en C en cuanto a sistemas embebidos se refiere.

Cuando es tema de software no tengo ningún inconveniente en escribir por ejemplo en C#.

Diría que es cuestión de enseñanza y de que parte de la ingeniería provengas, los ingenieros de sistemas manejan muy fácilmente el tema POO, en mi caso fue muy duro entender el concepto de clases sin que el subconsciente  lo relacionara con estructuras en C.

Pues entonces te comento que la única diferencia entre "class" y "struct" en C++ es que la primera, sus miembros son privados por defecto, mientras que en la segunda los miembros son públicos por defecto.

Ejemplo:

struct T1 {

  T1() : a(0), b(1), c(2)

  void getA() const { return a; }

private:

  int a, b, c;

};

Es equivalente a hacer

class T1 {

public:

  T1() : a(0), b(1), c(2)

  void getA() const { return a; }

private:

  int a, b, c;

}:

En definitiva, class y struct cumplen la misma función en el lenguaje, tienen las mismas capacidades y se usan de la misma forma, solo que en uno el scope es publico por defecto y en el otro es privado.

De hecho, algo como esto en C++:

struct T2 {

  int i;

  void inc() { i++; }

  void dec() { i--; }

};

Es el equivalente en C a:

struct T2 {

  int i;

};

void T2_inc(T2 *_this) {

  _this->i++;

}

void T2_dec(T2 *_this) {

  _this->i--;

}

Si nos metemos con las funciones virtuales las cosas se complican un poco pero no mucho mas. Básicamente se agrega un miembro llamado vtable que apunta a una struct (constante) que contiene los punteros de las funciones de esa clase. Tendríamos que hacer lo mismo en C para conseguir la misma funcionalidad que en C++.

Creo también, que el problema viene porque se piensa que la POO es el sumum de la informática cuando en realidad es una herramienta mas, ni funciona en todos los casos, ni es conveniente aplicarla para todo. C++ sabe esto, y por eso pone a disposición del programador otras herramientas, como la programación genérica, la metaprogramacion y la programación funcional.

Personalmente me gusta mucho lo que se puede hacer con metaprogramacion y programación funcional. Puede que con esas dos técnicas nunca necesitemos declarar una clase en la vida.

Todavía recuerdo la primera vez que vi esto:

while(true)

   apply_if([](auto& e) { return (timeslice() % 100_ms) == 0 }, { led1, led2, led3 }, toggle);

El código que genera es igual de eficiente que esto en C (que no equivalente):

led_t leds[] = { led1, led2, led3 };

while(1) {

   int i;

   dela_ms(100);

   for(i=0; i<2; i++)

     toggle(led[i]);

}

Y no, no hay división de por medio aunque aparesca un operador '%'

[martin ribelotta]

El 1 de marzo de 2018, 22:48, Eric Pernia <ericp...@gmail.com> escribió:

Yo creo que el tema es más de educación que tecnológico. 

En C++ se puede lograr el mismo rendimiento que en C. Y en ambos se puede incluir alguna función en assembler cuanddo estamos complicados con la performance de alguna función. Pasa por lo que sabe y le gusta a cada uno el aprovechar las cosas o pegarle a todo con el mismo martillo.

Habiendo dado clases tanto de programación muy básica de assembler, C, programación avanzada en C y POO para electrónica y automatización y control; y teniendo mucha relación con profesores y alumnos de carreras de sistemas y programación, resulta que depende todo del lado que se ven las cosas, en mi experiencia pasa esto:

Los alumnos de las carreras de electrónica detestan la abstracción de la POO, no quieren aprender a programar, si no los lenguajes que más puedan usar en un trabajo, y quieren saber que pasa con el bit en cada momento, disfrutan más las materias donde se ve toda la parte más física y de arquitectura que la programación abstracta. *

En el otro extremo tenemos los de las carreras de sistemas y programación quieren abstraerse completamente del hardware y trabajar en una máquina ideal que no quieren saber como funciona y le tienen asco a conectar cables, conocer la arquitectura a bajo nivel, pasan la única materia que ven de bajo nivel y arquitectura como un suplicio. *

Con lo cual queda bastante retratada la "impopularidad" de C++, requiere abstracción y no-abstracción al mismo tiempo.

[Xtian]

Quizás te interesa la opinión de el, 

http://harmful.cat-v.org/software/c++/linus

y la de el,

http://www.faqs.org/docs/artu/unix_and_oo.html

[Christian N]

Buenas

Cuando hablamos de embebido y lenguaje, ¿en que capa estamos? No se puede responder alegremente "en embebdidos se usa tal o cual cosa...", hay que diferenciar tipo de sistema, funcionalidad, presentacion etc.
A ver vamos por casos extremos si tengo que un micrito con 4k de memoria que lo tengo que usar para controlar dos portones, lo vamos a hacer en Python, xLANG, JAVA, C++, C, ASM, ahora un embebido como nuestro telefono, lo vamos a hacer en ASM, C, C++, JAVA (aca se usa de todo y cuando digo de todo es de to-do).
No quiero entrar en los sistemas de mision critica y ahi solo se pueden utllizar herramientas certificadas 

Por otra parte esta la herencia. En varios embebidos se utiliza un OS y/o bibliotecas, esto por lo general esta en C y con años de vuelo. Muchas veces un diseño se basa en el anterior, y ese en el anterior y ese, bueno ya se entendio la idea. ¿Cual es el lenguaje nativo del original? y si.. C y ASM. Cuando encaramos un nuevo diseño lo haremos escribiendo todo desde cero, obviamente no (razon obvia ya hay muchas cosas que se podrIA decir que funcionan ok, observen el potencial). De esto tampoco escapan los grandes proveedores TI. NXP etc, sus desarrollos por lo general se basan en uno anterior y hacen una minima portabilidad. El mundo esta asi y lo seguira estando.

Volviendo al asunto de esta cadena
¿Que procesador se va a utilizar?
¿Que tipo de sistema y mision se quiere implementar?
¿Requiere OS?
¿Debe ejecutar programas de terceros?
Etc etc Definamos entorno y hagamos mas concreto el debate

[Gustavo F. Paredes - LU2JGP]

Bueno, hablando de portabilidad y usar lo ya hiper probado...

https://rmcantin.wordpress.com/2011/03/24/ariane-5-vuelo-501-una-cadena-de-despropositos/

No siempre termina todo bien...

Saludos.

Gustavo Paredes

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

"Per Aspera ad Astra"
Gustavo F. Paredes Delaloye

--

Técnico en Computación.
Técnico Superior en Electrónica Digital y Control Automático.
Profesor para el Nivel Secundario en la Modalidad Técnico-Profesional.

Técnico Universitario en Automatización y Control de Procesos Industriales.
Matricula Nacional COPITEC T3018

--

My LinkedIn

Skype: lu2jgp

lu2...@gmail.com

pared...@gmail.com
--
Labalta 127
Concepción del Uruguay, Entre Ríos
Argentina
Tel.: +54 3442 443731
Movil: +54 9 3442 540623

[Agustin Bonelli]

Para simplificar la discusión, cuando me referí a sistema embebido, me referia a sistemas caracterizador por algun tipo de procesador que ejecuta instrucciones, y cuyo conjunto de funcionalidades esta predefinida, y el usuario no tiene forma de agregarle nueva funcionalidad, ni instalando programas ni plugins ni nada por el estilo. Sencillo, lo que en general se suele entender. Un aparatito que corre un ejecutable establecido por el programador (con o sin OS, o RTOS, da lo mismo).

Se puede hacer en C, C++, python, micropython, o la plataforma que sea. El objetivo del desarrollador en este caso siempre suele ser, crear uno (o varios, ej: bootloader e imagen principal) archivo/s binarios con instrucciones de maquina para el chip que eligió.

---

From: embeb...@googlegroups.com <embeb...@googlegroups.com> on behalf of Gustavo F. Paredes - LU2JGP <lu2...@gmail.com>
Sent: Friday, March 2, 2018 3:17 PM
To: embeb...@googlegroups.com
Subject: Re: [embeb32] Uso de C++ en sistemas embebidos.

 

Bueno, hablando de portabilidad y usar lo ya hiper probado...

https://rmcantin.wordpress.com/2011/03/24/ariane-5-vuelo-501-una-cadena-de-despropositos/

Ariane 5, Vuelo 501. Una cadena de despropositos ... rmcantin.wordpress.com El fallo del vuelo 501 del Ariane 5 quizá se haya convertido en el primer bug informático de consecuencias catastróficas. Image from Wikipedia, using GNU FDL. En ...

No siempre termina todo bien...

Saludos.

Gustavo Paredes

El 2 de marzo de 2018, 10:27, Christian N <cneg...@gmail.com> escribió:

Buenas

Cuando hablamos de embebido y lenguaje, ¿en que capa estamos? No se puede responder alegremente "en embebdidos se usa tal o cual cosa...", hay que diferenciar tipo de sistema, funcionalidad, presentacion etc.
A ver vamos por casos extremos si tengo que un micrito con 4k de memoria que lo tengo que usar para controlar dos portones, lo vamos a hacer en Python, xLANG, JAVA, C++, C, ASM, ahora un embebido como nuestro telefono, lo vamos a hacer en ASM, C, C++, JAVA (aca se usa de todo y cuando digo de todo es de to-do).
No quiero entrar en los sistemas de mision critica y ahi solo se pueden utllizar herramientas certificadas 

Por otra parte esta la herencia. En varios embebidos se utiliza un OS y/o bibliotecas, esto por lo general esta en C y con años de vuelo. Muchas veces un diseño se basa en el anterior, y ese en el anterior y ese, bueno ya se entendio la idea. ¿Cual es el lenguaje nativo del original? y si.. C y ASM. Cuando encaramos un nuevo diseño lo haremos escribiendo todo desde cero, obviamente no (razon obvia ya hay muchas cosas que se podrIA decir que funcionan ok, observen el potencial). De esto tampoco escapan los grandes proveedores TI. NXP etc, sus desarrollos por lo general se basan en uno anterior y hacen una minima portabilidad. El mundo esta asi y lo seguira estando.

Volviendo al asunto de esta cadena
¿Que procesador se va a utilizar?
¿Que tipo de sistema y mision se quiere implementar?
¿Requiere OS?
¿Debe ejecutar programas de terceros?
Etc etc Definamos entorno y hagamos mas concreto el debate

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

Grupos de Google groups.google.com Grupos de Google te permite crear y participar en foros online y en grupos basados en correo electrónico con una amplia experiencia en conversaciones de comunidades.

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

"Per Aspera ad Astra"
Gustavo F. Paredes Delaloye

--

Técnico en Computación.
Técnico Superior en Electrónica Digital y Control Automático.
Profesor para el Nivel Secundario en la Modalidad Técnico-Profesional.

Técnico Universitario en Automatización y Control de Procesos Industriales.
Matricula Nacional COPITEC T3018

--

My LinkedIn

Skype: lu2jgp

lu2...@gmail.com

pared...@gmail.com
--
Labalta 127
Concepción del Uruguay, Entre Ríos
Argentina
Tel.: +54 3442 443731
Movil: +54 9 3442 540623

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Alejandro Celery]

El viernes, 2 de marzo de 2018, 10:36:04 (UTC-5), Bone escribió:

Para simplificar la discusión, cuando me referí a sistema embebido, me referia a sistemas caracterizador por algun tipo de procesador que ejecuta instrucciones, y cuyo conjunto de funcionalidades esta predefinida, y el usuario no tiene forma de agregarle nueva funcionalidad, ni instalando programas ni plugins ni nada por el estilo. Sencillo, lo que en general se suele entender. Un aparatito que corre un ejecutable establecido por el programador (con o sin OS, o RTOS, da lo mismo).

Se puede hacer en C, C++, python, micropython, o la plataforma que sea. El objetivo del desarrollador en este caso siempre suele ser, crear uno (o varios, ej: bootloader e imagen principal) archivo/s binarios con instrucciones de maquina para el chip que eligió.

Eso no es simplificar la discusión sino todo lo contrario de simplificar la discusión, es ampliarla.
"algun tipo de procesador que ejecuta instrucciones" es TODO procesador basado en las ideas de Turing.
"Se puede hacer en C, C++, python, micropython, o la plataforma que sea" me dice que puedo poner una notebook entera cerrada con un candado (acéptenme esta metáfora por favor) para que no se le pueda modificar la funcionalidad.

Yo creo que en las preguntas que te hacen está la respuesta que vos buscás y se parece bastante a "Porque hay que ser macho para hacer embebidos en C++!!!" (Martín Ribelotta lo dijo más elegantemente que yo).

Al margen de este comentario, mi respuesta formal es "porque es más difícil saber lo que estás haciendo". Pero claro que mientras uno sepa lo que está haciendo (o al menos verifique y valide sus resultados) se puede hacer perfectamente.

Saludos!

[martin ribelotta]

El 2 de marzo de 2018, 15:59, Alejandro Celery <alejand...@gmail.com> escribió:

El viernes, 2 de marzo de 2018, 10:36:04 (UTC-5), Bone escribió:

Para simplificar la discusión, cuando me referí a sistema embebido, me referia a sistemas caracterizador por algun tipo de procesador que ejecuta instrucciones, y cuyo conjunto de funcionalidades esta predefinida, y el usuario no tiene forma de agregarle nueva funcionalidad, ni instalando programas ni plugins ni nada por el estilo. Sencillo, lo que en general se suele entender. Un aparatito que corre un ejecutable establecido por el programador (con o sin OS, o RTOS, da lo mismo).

Se puede hacer en C, C++, python, micropython, o la plataforma que sea. El objetivo del desarrollador en este caso siempre suele ser, crear uno (o varios, ej: bootloader e imagen principal) archivo/s binarios con instrucciones de maquina para el chip que eligió.

Eso no es simplificar la discusión sino todo lo contrario de simplificar la discusión, es ampliarla.
"algun tipo de procesador que ejecuta instrucciones" es TODO procesador basado en las ideas de Turing.
"Se puede hacer en C, C++, python, micropython, o la plataforma que sea" me dice que puedo poner una notebook entera cerrada con un candado (acéptenme esta metáfora por favor) para que no se le pueda modificar la funcionalidad.

Yo creo que en las preguntas que te hacen está la respuesta que vos buscás y se parece bastante a "Porque hay que ser macho para hacer embebidos en C++!!!" (Martín Ribelotta lo dijo más elegantemente que yo).

No se si tanto, pero es cierto que a mayor nivel de abstracción y a mayor capacidad de expresion hay que tener mas claro el concepto que se usa, o cuando y como usar tal o cual herramienta.

De todas formas, creo que es pertinente la frase:

"En C cuando cometes un error, es como pegarse un tiro en la pierna, en C++ un error significa pegarse un tiro en la pierna, con un cañón... que tira ojivas nucleares: si te pegas un tiro en la pierna, te la vuelas, y todo a tu alrededor"

 

Al margen de este comentario, mi respuesta formal es "porque es más difícil saber lo que estás haciendo". Pero claro que mientras uno sepa lo que está haciendo (o al menos verifique y valide sus resultados) se puede hacer perfectamente.

Saludos!

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

[Rodrigo Pardo]

Y en el medio estamos los Ingenieros en Computación de universidades como la Nacional de La Plata o de Córdoba que tenemos formación en electrónica y en informática. Así no le tenemos miedo a la POO ni a los transistores.

¡Para tener en cuenta!


Saludos,

Rodrigo

Amplio entre lineas:

 

Espero sus opiniones!

Saludos!

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Santiago Germino]

Hola! Bone, en respuesta a tu pregunta... C es un lenguaje de sistema (operativo), para eso nacio. Una API de bajo nivel queda mas clara (con tipos de dato nativos y manejo de memoria directo) y asi se pueden realizar bindings de forma mucho mas sencilla a cualquier otro lenguaje.

Lamentablemente el parecido de C++ con C (es ampliamente extendido el concepto de que "C++ es C con clases" o "C++ es para hacer aplicaciones visuales") hace que mucha gente subestime a C++. En mi epoca de programador C++ teniamos largos debates con mi compañero sobre patrones de diseño y sobre el uso mismo del lenguaje y de la STL y Boost en la implementacion de una aplicacion bastante grande y modular.

C++ como lenguaje es 10 veces (por decir algo) mas extenso que C y la teoria necesaria para utilizar bien el poder de la herramienta es tambien mucho mas extensa que la necesaria para usar C de forma eficaz. Me parece que el buen uso de templates por si solo es mas dificil de aprender que el buen uso de todo el lenguaje C en si mismo.

Resumiendo, C es simple de entender y los conceptos a manejar no son para nada abstractos y teoricos como en C++, sino mas bien practicos y fisicos, bien pegados al bajo nivel de un micro. Eso es una ventaja! Para que usar "C con clases" o mal C++, cuando con buen C puede hacerse lo mismo, mejor y mas claro?

No se si ese es el motivo por el cual muchos usan C en embebidos, pero yo lo uso por eso!

Saludos,
Santiago.

[Agustin Bonelli]

Hola Santiago, 

Entiendo tu punto y si estoy de acuerdo (a grandes rasgos) con lo que decis que C++ es mas extenso y mas complejo de entender y de usar bien. Por otro lado, creo que a tu comentario final le falto agregar que con C se puede hacer lo mismo, no se si mejor pero al menos igual de bien (o con C++ hay mas chances de hacer cualquier verdura y enrollarse por demas), mas claro, pero te toma el doble o el triple de tiempo que hacerlo con C++, y te forzas a tener que duplicar o triplicar el tiempo de mantenimiendo de la aplicacion por siempre.
Me parece que el tema hay que verlo desde el punto de vista de que, con C++ se puede hacer lo mismo que C (tenes el mismo control a bajo nivel si lo deseas), pero tambien tenes otras herramientas a tu disposicion mas potentes. 
Creo que la conclusion es que muchas industrias eligen C, porque pareciera ser que hay menos chances de cagarla y generar un codigo espaghet inmantenible. Aunque en la practica, he visto mas codigo espagheti escrito en C que en C++.

Saludos

Agustin

---

From: embeb...@googlegroups.com <embeb...@googlegroups.com> on behalf of Santiago Germino <royc...@gmail.com>
Sent: Saturday, March 24, 2018 7:20 AM
To: Embebidos32
Subject: [embeb32] Re: Uso de C++ en sistemas embebidos.

 

--

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

Grupos de Google groups.google.com Grupos de Google te permite crear y participar en foros online y en grupos basados en correo electrónico con una amplia experiencia en conversaciones de comunidades.

[Santiago Germino]

Hola Agustin, es cierto lo que decis sobre el poder de sintesis y abstraccion de buen codigo en C++. Justamente el problema es ese: el lenguaje es tan potente y diverso que si no se decide limitar su uso a un pequeño subset de sus posibilidades (como hizo Qt), si realmente fue escrito por alguien experto que luego se va de la empresa, ese codigo se vuelve incomprensible e inmantenible! C es transparente y el problema en todo caso seria de estilo.

Ultimamente se esta usando mucho Qt en sistemas embebidos, pero eso corre en hardware multicore en Linux o Android (como cualquier celu) y no en los Bare Metal que suelen darse en la facu.

Como varios ya dijeron, es verdad que ahi falta cubrir un bache educativo, pero estando tan a alto nivel, no se si sea deber de un ingeniero o ya de alguna especialidad en sistemas!

Saludos,

Santiago.

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/WbQ21_Jaurw/unsubscribe.
Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

[martin ribelotta]

El 24 de marzo de 2018, 12:41, Santiago Germino <royc...@gmail.com> escribió:

Hola Agustin, es cierto lo que decis sobre el poder de sintesis y abstraccion de buen codigo en C++. Justamente el problema es ese: el lenguaje es tan potente y diverso que si no se decide limitar su uso a un pequeño subset de sus posibilidades (como hizo Qt), si realmente fue escrito por alguien experto que luego se va de la empresa, ese codigo se vuelve incomprensible e inmantenible! C es transparente y el problema en todo caso seria de estilo.

> C

> entendible

https://www.ioccc.org/2015/dogon/prog.c

En cualquier lenguaje se pueden hacer virgerias. Solo que lenguajes mas extensos permiten virgerias mas extensas, pero tambien permiten expreciones mas fuertes y mantenibles.

Escribir codigo mantenible exige esfuerzo, escribir codigo espagetti lo hace cualquiera aunque no sepa programar.

De hecho:

(*((volatile unsigned int*)0xDEADBEEF)) ^= (((int)(-1))-2) >> (((*((volatile unsigned int*)0xDAA7B00B)) & (1 << ((-1) & 0xff)))?

    (*((volatile unsigned int)0xCAFEF00D)) : (*((volatile unsigned int)0xBEA71337)));

Compite con codigo PERL del mas alto nivel y es perfectamente valido, funcional y correcto (de hecho esta correctamente formateado y sigue las mejores coding guidelines)

Eso si, hay que tener los perifericos correctamente mapeados en 0xDEADBEEF, 0xDAA7B00B, 0xCAFEF00D y 0xBEA71337.

Podrias dar un ejemplo de donde Qt usa solo un subset de C++? Yo me he visto codigo de Qt usando templates y metaprogramming como campeones para hacer cosas como estas:

http://wiki.qt.io/New_Signal_Slot_Syntax#Asynchronous_made_easier

(esto requiere metaprogramacion para elegir el tipo de sobrecarga y hacer un type erasure sobre el lambda envolviendolo en un functor llamable desde un slot ya que no usa std::function)

Si es cierto que Qt no usa las STL pero eso es porque sus librerias de templates funcionan muy bien y se integran perfectamente con el resto del sistema, pero dudo que en embebidos sea buena idea usar STL, salvo que hagamos nuestros propios allocators.

 

Ultimamente se esta usando mucho Qt en sistemas embebidos, pero eso corre en hardware multicore en Linux o Android (como cualquier celu) y no en los Bare Metal que suelen darse en la facu.

http://blog.qt.io/blog/2016/08/18/introducing-the-qt-lite-project-qt-for-any-platform-any-thing-any-size/

La idea es llevarlo a que incluso pueda ejecutarse sin sistema operativo... por supuesto, de aquí a eso, faltan años...

 

Como varios ya dijeron, es verdad que ahi falta cubrir un bache educativo, pero estando tan a alto nivel, no se si sea deber de un ingeniero o ya de alguna especialidad en sistemas!

En este punto el deber de un ingeniero es hacer el trabajo que se le encomienda, si tiene que escribir en alto nivel lo hace, si tiene que programar en assembler si hace, si tiene que programar en VHDL/Verilog o cualquier HDL se hace, si tiene que soldar se hace, si tiene que armar un setup analógico lo hace, si tiene que medir el ROE de una antena lo hace, y si tiene que ir a destapar el baño también lo hace... en este país no nos podemos dar el lujo de ser especializados exclusivos, al contrario tenemos que ser multiespecialisas.

Como digo, abogo por la mutli-especializacion (o sea ser maestro de todo luego de haber sido aprendiz de todo). Yo digo que no nos detengamos a pensar en cual es el limite de tal o cual ingenieria sino en que hace falta para resolver los problemas que se nos presenta.

 

Saludos,

Santiago.

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

Grupos de Google groups.google.com Grupos de Google te permite crear y participar en foros online y en grupos basados en correo electrónico con una amplia experiencia en conversaciones de comunidades.

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/WbQ21_Jaurw/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32+unsubscribe@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---

Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32+unsubscribe@googlegroups.com.

[Hernan]

Muy bueno el debate y los puntos de vista, según el contexto en que cada uno se encuentra, concuerdo.    El contexto es muy importante en la aplicación de herramientas.

Un poco de humor con todo respeto:   Cuanto más escucho hablar de C y C++, encuentro que el problema se encuentra entre el teclado y la silla.

Como han dicho, todo depende, hay que evaluar el proyecto y sus requerimientos  (presupuesto, recursos, complejidad, plataforma, etc).

Hoy día cada vez escucho más desarrolladores que dicen: "Si estoy con el tema de pequeños devices,  puse una RaspberryPi"

Han participado de un proyecto grande en C? ejemplo para noción de grande:  ~1MM lineas de código y ~50 programadores?

Y uno grande en  C++ ?   (dejemos de lado proyectos conocidos como el Kernel de Linux, hablemos dentro de estructuras de empresas/negocios)

Que opinan ?   C ó C++

Creo que ahí radican interesantes diferencias con respecto a productividad, mantenimiento,  etc.

Pienso que OOP adiciona beneficios en grandes proyectos,  mucha gente, equipos distribuidos, etc.

Para mencionar un caso de análisis:   AOSP,   donde parte es en C,  otra en C++,  luego Java/Kotlin/etc   los actores que intervienen en un producto (distintas empresas, grupos de desarrollos,  distintos objetivos/fuentes de beneficio comercial)

Creo que uno de los valores importantes del Ingeniero es que sepa asesorar en la mejor opción durante la evaluación del proyecto,  y si tiene que luego ser parte del desarrollo,  haber elegido las herramientas adecuadas.

En casa y para aprender nos podemos enroscar en cosas difíciles, meter de todo por gusto y amor,  pero en los negocios,  KISS. 

Saludos,

Santiago.

-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

Grupos de Google groups.google.com Grupos de Google te permite crear y participar en foros online y en grupos basados en correo electrónico con una amplia experiencia en conversaciones de comunidades.

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
---

Has recibido este mensaje porque estás suscrito a un tema del grupo "Embebidos32" de Grupos de Google.
Para cancelar la suscripción a este tema, visita https://groups.google.com/d/topic/embebidos32/WbQ21_Jaurw/unsubscribe.

Para cancelar la suscripción a este grupo y a todos sus temas, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Santiago Germino]

Muy bueno tu punto Hernan. Siempre alguien toma la decision tecnica del como y con que. Seria ideal, pero muchas veces eso dista de un KISS y muchos negocios fracasan por eso.

No es el caso, pero Autodesk es una empresa grande que tiene proyectos enormes en C++. Estan volviendose locos para encontrar programadores C++ con experiencia suficiente para meterse a tocar el codigo. Tienen que terminar pagando extremadamente bien en relacion a otros lenguajes y aun asi no encuentran gente.

Entonces la herramienta es la correcta pero termina siendo dificil de mantener por lo especializados que deben estar los recursos humanos!

Saludos,

Santiago.

[Santiago Germino]

Hola Martin, te respondo lo mio entre lineas!

Podrias dar un ejemplo de donde Qt usa solo un subset de C++? Yo me he visto codigo de Qt usando templates y metaprogramming como campeones para hacer cosas como estas:

http://wiki.qt.io/New_Signal_Slot_Syntax#Asynchronous_made_easier

En sus origenes, los de Qt decidieron quedarse con un subset de C++ para facilitar la portabilidad. Por eso tambien reimplementaron funcionalidad de la STL y para signal/slots hicieron el MOC, algo que siempre fue muy criticado. Ya hace unos cuantos años que existen las lambda functions (C++11 si mal no recuerdo) y Boost tiene signal/slots, reflection y hace lo mismo y mas que Qt hace sin requerir de otras herramientas de compilacion. Tampoco es un dato menor que los errores de compilacion kilometricos de STL/Boost asustan a cualquiera y no es igual que entender el error que sea compilando C.

En este punto el deber de un ingeniero es hacer el trabajo que se le encomienda, si tiene que escribir en alto nivel lo hace, si tiene que programar en assembler si hace, si tiene que programar en VHDL/Verilog o cualquier HDL se hace, si tiene que soldar se hace, si tiene que armar un setup analógico lo hace, si tiene que medir el ROE de una antena lo hace, y si tiene que ir a destapar el baño también lo hace... en este país no nos podemos dar el lujo de ser especializados exclusivos, al contrario tenemos que ser multiespecialisas.

Como digo, abogo por la mutli-especializacion (o sea ser maestro de todo luego de haber sido aprendiz de todo). Yo digo que no nos detengamos a pensar en cual es el limite de tal o cual ingenieria sino en que hace falta para resolver los problemas que se nos presenta.

Eso es ir a contramano de lo que hace y pide el mundo. Las cosas ya no son tan simples como para creer que uno puede ser suficientemente bueno en todo. Que nosotros no podamos entrar en ese esquema de epecializacion (sea por falta de recursos, de capacitacion o de organizacion) es una limitacion, no una fortaleza. Ademas de ser un mal sintoma de la seriedad o rigurosidad (desapego a los protocolos y las normas internacionales) con la que tomamos un trabajo.

Ejemplos hay miles, mas si uno trabajo en una empresa grande y por lo menos en automatizacion industrial que es donde conozco.

Saludos,

Santiago.

[Alejandro Armanazqui]

Bone, metiste el dedo en la llaga, a fondo. Eso no se pregunta, es como preguntar cuál es la mejor religion o cual es el mejor partido político. Yo programo desde los 17 y ya tengo 51, empece con el BASIC luego Pascal y finalmente C. Cuando salió el C++ me mudé inmediatamente al “nuevo lenguaje de los ’80”, era joven, inexperto y no sabía nada sobre modelo de datos, acoplamiento, BPM, etc. Realicé grandes sistemas en C y en C++, por eso sigo eligiendo el C. Pero realizar un sistema significa resolver muchos problemas a la vez y no existe la herramienta o lenguaje mágicos que resuelven todos los problemas. 

Respecto del C, como decía Clua (profesor de la UBA) el C no es un lenguaje, es un ensamblador enmascarado. Y como para trabajar sobre un micro no hay nada mejor que un ensamblador, el “C” es la elección ideal. 

Respecto del C++, para mi es un híbrido que se quedó a mitad de camino entre lo estático y lo dinámico. Recordemos que la Programación Orientada a Objetos es un concepto y no un lenguaje. Un verdadero lenguaje OO debe ser interpretado y no compilado.

Si bien hay infinidad de puntos a observar, un sistema “bien escrito” en “C” y “bien documentado” es mucho mas mantenible y debugeable que el mismo escrito en C++. Y el problema del C++ no está en el lenguaje en si, dado que no deja de ser un “C” extendido, sino en el árbol de herencias, en la sobre carga de operadores, etc. que lo hacen muy poco modificable a lo largo del tiempo, muy complicado de debuguear, etc.

[martin ribelotta]

Hoy toca responder mails despues de desaparecer por un laaargo tiempo jejeje. Asi que va entre linas.

El 24 de marzo de 2018, 16:10, Santiago Germino <royc...@gmail.com> escribió:

Hola Martin, te respondo lo mio entre lineas!

Podrias dar un ejemplo de donde Qt usa solo un subset de C++? Yo me he visto codigo de Qt usando templates y metaprogramming como campeones para hacer cosas como estas:

http://wiki.qt.io/New_Signal_Slot_Syntax#Asynchronous_made_easier

En sus origenes, los de Qt decidieron quedarse con un subset de C++ para facilitar la portabilidad. Por eso tambien reimplementaron funcionalidad de la STL y para signal/slots hicieron el MOC, algo que siempre fue muy criticado. Ya hace unos cuantos años que existen las lambda functions (C++11 si mal no recuerdo) y Boost tiene signal/slots, reflection y hace lo mismo y mas que Qt hace sin requerir de otras herramientas de compilacion. Tampoco es un dato menor que los errores de compilacion kilometricos de STL/Boost asustan a cualquiera y no es igual que entender el error que sea compilando C.

No, en su origen, los compiladores de C++ eran dispares y no existia un estandar tan fuerte (ni en API ni en ABI). De hecho, Qt hace las cosas que hace porque gcc (en aquel entonces ECG), ibm C++, Borland C++ y otros hacian cosas realmente feas apra aliviarles la vida al usuario con las STL, las excepciones y demas (de ahi el hecho que no se use excepciones)

Basicamente fue tomar el comun denominador de C++ para todos los compiladores existentes y hacer algo usable (y bien usable) entre ellos.

En cuanto a los errores de compilacion, es inherente al mecanismo de templates. En c++17 se esperaba miticar esto con los "concepts" que eran un conjunto de regstricciones (o declaracion de conceptos requeridos) a los templates para asi rastrear mejor los errores. Discuciones muy tecnicas de por medio, quedaron para C++20.

 

En este punto el deber de un ingeniero es hacer el trabajo que se le encomienda, si tiene que escribir en alto nivel lo hace, si tiene que programar en assembler si hace, si tiene que programar en VHDL/Verilog o cualquier HDL se hace, si tiene que soldar se hace, si tiene que armar un setup analógico lo hace, si tiene que medir el ROE de una antena lo hace, y si tiene que ir a destapar el baño también lo hace... en este país no nos podemos dar el lujo de ser especializados exclusivos, al contrario tenemos que ser multiespecialisas.

Como digo, abogo por la mutli-especializacion (o sea ser maestro de todo luego de haber sido aprendiz de todo). Yo digo que no nos detengamos a pensar en cual es el limite de tal o cual ingenieria sino en que hace falta para resolver los problemas que se nos presenta.

Eso es ir a contramano de lo que hace y pide el mundo. Las cosas ya no son tan simples como para creer que uno puede ser suficientemente bueno en todo. Que nosotros no podamos entrar en ese esquema de epecializacion (sea por falta de recursos, de capacitacion o de organizacion) es una limitacion, no una fortaleza. Ademas de ser un mal sintoma de la seriedad o rigurosidad (desapego a los protocolos y las normas internacionales) con la que tomamos un trabajo.

Lo que hace y pide un sector del mundo... Entiendo que en automatizacion industrial se pueden dar el lujo de especializarse y expertizarse en una sola cosa, pero en I+D es imposible pensar en algo como eso. De hecho, si me lo hubieras planteado a ppio de siglo XXI te daria la razon, pero hoy el mundo justamente migra a una interdisiplina que, si bien no requiere experticia en todas las areas, si requiere saber la mayor cantidad de conceptos posibles y poder hablar de tu-a-tu con los expertos (como minimo)

 

Ejemplos hay miles, mas si uno trabajo en una empresa grande y por lo menos en automatizacion industrial que es donde conozco.

Concretamente, automatizacion indistrual: produccion por encima de desarrollo. Sacar cosas rapido usando lo ya probado. No I+D donde se debe inventar lo que no existe.

 

Saludos,

Santiago.

[martin ribelotta]

El 28 de marzo de 2018, 22:27, Alejandro Armanazqui <alejan...@gmail.com> escribió:

Bone, metiste el dedo en la llaga, a fondo. Eso no se pregunta, es como preguntar cuál es la mejor religion o cual es el mejor partido político. Yo programo desde los 17 y ya tengo 51, empece con el BASIC luego Pascal y finalmente C. Cuando salió el C++ me mudé inmediatamente al “nuevo lenguaje de los ’80”, era joven, inexperto y no sabía nada sobre modelo de datos, acoplamiento, BPM, etc. Realicé grandes sistemas en C y en C++, por eso sigo eligiendo el C. Pero realizar un sistema significa resolver muchos problemas a la vez y no existe la herramienta o lenguaje mágicos que resuelven todos los problemas. 

Respecto del C, como decía Clua (profesor de la UBA) el C no es un lenguaje, es un ensamblador enmascarado. Y como para trabajar sobre un micro no hay nada mejor que un ensamblador, el “C” es la elección ideal. 

Respecto del C++, para mi es un híbrido que se quedó a mitad de camino entre lo estático y lo dinámico. Recordemos que la Programación Orientada a Objetos es un concepto y no un lenguaje. Un verdadero lenguaje OO debe ser interpretado y no compilado.

Eso conceptualmente no tiene mucho sentido. Porque el concepto de POO deberia estar ligado a interpretado o compilado? De hecho, hoy lo interpretado es cada vez mas desaconsejado siendo la tendencia el JIT y la emicion de codigo AOT (ahead on time)

De todas formas, C++ es un lenguaje multiparadigma (de ahi que digas que es un hibrido) pero asi es en la mayoria de lenguajes de programación, siendo los casos emblematicos Java, Objetive-C y C#. Todos lenguajes que siguen la linea de C++ del multiparadigma (no, desde el momento que java define tipos nativos deja de ser POO puro y desde el momento que permite metodos de clase -estaticos- deja de ser un lenguaje POO correcto -ciñendonos a la definición de POO original de Simula 67)

Si bien hay infinidad de puntos a observar, un sistema “bien escrito” en “C” y “bien documentado” es mucho mas mantenible y debugeable que el mismo escrito en C++. Y el problema del C++ no está en el lenguaje en si, dado que no deja de ser un “C” extendido, sino en el árbol de herencias, en la sobre carga de operadores, etc. que lo hacen muy poco modificable a lo largo del tiempo, muy complicado de debuguear, etc.

Lo mismo corre para un sistema "bien escrito en C++". No entiendo cual seria la diferencia salvo que C te da menos herramientas para cagarla. Es decir, un mono con una navaja es menos peligroso que un mono saltando sobre un boton nuclear, pero eso no es culpa ni de la navaja ni del boton nuclear. 

[Ing. Mirko Serra]

A mi entender, es al revés: C++ te da más herramientas para no cagarla a la vez que hacés código más legible.

En C cualquier cast da algo válido (fruta).

En C++ dynamic_cast<Perro*>(gato) da nullptr y static_cast se queja al compilar.

En C los enums son números y hacer setColor(PIZZA) es válido. En C++ no, y es cosa del compilador en la que no se incurre en penalización.

En C hay funciones que devuelven 0 en error ("false") y hay funciones que devuelven -1 en error y 0 es todo bien. En C++ podés hacer que esa función devuelva Archivo::OK que no solo es independiente numéricamente de Socket::OK, sino que no es válido compararlas. Nuevamente, esto es sin costo para el programa.

Ni hablar de las funciones que devuelven un puntero en C, que puede ser que haya que liberarlo uno o no. En C++ podrías devolver una instancia de un unique_ptr y es mucho más difícil que haya leak.

Por eso, C++ es más poderoso, pero con buenas prácticas es mucho más seguro. Es exactamente el botón nuclear: requiere el portafolios con los códigos y el escaneo de retina. No lo activa un mono con un martillo.

Saludos.

Ing. Mirko Serra.

[martin ribelotta]

Jajajaja ok ok, es cierto. En si, C++ provee mas herramientas que C (eso es totalmente objetivo).

Como bien decís, Mirko, bien usadas son una bendición para poder mejorar tu código, tu legibilidad y dejarle al compilador la tarea de detectar errores en el código (con mas poder de expresion)

De todas formas, como también tenes muchas herramientas, también podes conjugarlas de formas truculentas para hacer esoterismo pagano y termina invocando a David Bisbal.

[Jonathan Marino]

Hola,

Este hilo se hizo bastante largo y no quiero más que aportar algunas fuentes.

En mi caso me gusta mucho la programación orientada a objetos en C por varias cosas y para el que le interese en algunos meses voy a publicar un generador de código oo C desde UML para 3 frameworks.

recomiendo ver la siguiente crítica a C++, sobre todo por de quien parte: http://yosefk.com/blog/oo-c-is-passable.html

También ver el siguiente framework OO C y ver la critica a C++ en manual/Dynace.pdf : https://github.com/blakemcbride/Dynace

Para ver un framework (casi no más que una librería C) que extiende increíblemente a C entrar a: https://github.com/CObjectSystem/COS

Saludos,

El martes, 3 de abril de 2018, 15:55:47 (UTC-3), El Ruso escribió:

Jajajaja ok ok, es cierto. En si, C++ provee mas herramientas que C (eso es totalmente objetivo).

Como bien decís, Mirko, bien usadas son una bendición para poder mejorar tu código, tu legibilidad y dejarle al compilador la tarea de detectar errores en el código (con mas poder de expresion)

De todas formas, como también tenes muchas herramientas, también podes conjugarlas de formas truculentas para hacer esoterismo pagano y termina invocando a David Bisbal.

El 3 de abril de 2018, 15:22, Ing. Mirko Serra <mirko...@gmail.com> escribió:

A mi entender, es al revés: C++ te da más herramientas para no cagarla a la vez que hacés código más legible.

En C cualquier cast da algo válido (fruta).

En C++ dynamic_cast<Perro*>(gato) da nullptr y static_cast se queja al compilar.

En C los enums son números y hacer setColor(PIZZA) es válido. En C++ no, y es cosa del compilador en la que no se incurre en penalización.

En C hay funciones que devuelven 0 en error ("false") y hay funciones que devuelven -1 en error y 0 es todo bien. En C++ podés hacer que esa función devuelva Archivo::OK que no solo es independiente numéricamente de Socket::OK, sino que no es válido compararlas. Nuevamente, esto es sin costo para el programa.

Ni hablar de las funciones que devuelven un puntero en C, que puede ser que haya que liberarlo uno o no. En C++ podrías devolver una instancia de un unique_ptr y es mucho más difícil que haya leak.

Por eso, C++ es más poderoso, pero con buenas prácticas es mucho más seguro. Es exactamente el botón nuclear: requiere el portafolios con los códigos y el escaneo de retina. No lo activa un mono con un martillo.

Saludos.

Ing. Mirko Serra.

El 3 de abril de 2018, 15:01, martin ribelotta <martinr...@gmail.com> escribió:

El 28 de marzo de 2018, 22:27, Alejandro Armanazqui <alejan...@gmail.com> escribió:

Bone, metiste el dedo en la llaga, a fondo. Eso no se pregunta, es como preguntar cuál es la mejor religion o cual es el mejor partido político. Yo programo desde los 17 y ya tengo 51, empece con el BASIC luego Pascal y finalmente C. Cuando salió el C++ me mudé inmediatamente al “nuevo lenguaje de los ’80”, era joven, inexperto y no sabía nada sobre modelo de datos, acoplamiento, BPM, etc. Realicé grandes sistemas en C y en C++, por eso sigo eligiendo el C. Pero realizar un sistema significa resolver muchos problemas a la vez y no existe la herramienta o lenguaje mágicos que resuelven todos los problemas. 

Respecto del C, como decía Clua (profesor de la UBA) el C no es un lenguaje, es un ensamblador enmascarado. Y como para trabajar sobre un micro no hay nada mejor que un ensamblador, el “C” es la elección ideal. 

Respecto del C++, para mi es un híbrido que se quedó a mitad de camino entre lo estático y lo dinámico. Recordemos que la Programación Orientada a Objetos es un concepto y no un lenguaje. Un verdadero lenguaje OO debe ser interpretado y no compilado.

Eso conceptualmente no tiene mucho sentido. Porque el concepto de POO deberia estar ligado a interpretado o compilado? De hecho, hoy lo interpretado es cada vez mas desaconsejado siendo la tendencia el JIT y la emicion de codigo AOT (ahead on time)

De todas formas, C++ es un lenguaje multiparadigma (de ahi que digas que es un hibrido) pero asi es en la mayoria de lenguajes de programación, siendo los casos emblematicos Java, Objetive-C y C#. Todos lenguajes que siguen la linea de C++ del multiparadigma (no, desde el momento que java define tipos nativos deja de ser POO puro y desde el momento que permite metodos de clase -estaticos- deja de ser un lenguaje POO correcto -ciñendonos a la definición de POO original de Simula 67)

Si bien hay infinidad de puntos a observar, un sistema “bien escrito” en “C” y “bien documentado” es mucho mas mantenible y debugeable que el mismo escrito en C++. Y el problema del C++ no está en el lenguaje en si, dado que no deja de ser un “C” extendido, sino en el árbol de herencias, en la sobre carga de operadores, etc. que lo hacen muy poco modificable a lo largo del tiempo, muy complicado de debuguear, etc.

Lo mismo corre para un sistema "bien escrito en C++". No entiendo cual seria la diferencia salvo que C te da menos herramientas para cagarla. Es decir, un mono con una navaja es menos peligroso que un mono saltando sobre un boton nuclear, pero eso no es culpa ni de la navaja ni del boton nuclear. 

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--
-- Recibiste este mensaje porque estás suscripto al Grupo Google Embebidos32. Para postear en este grupo, escribe un email a embeb...@googlegroups.com. Para des-suscribirte, envía un email a embebidos32...@googlegroups.com. Para más opciones, visita el sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es

---
Has recibido este mensaje porque estás suscrito al grupo "Embebidos32" de Grupos de Google.

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a embebidos32...@googlegroups.com.

[Salvador Eduardo Tropea]

On 05/04/18 05:37, Jonathan Marino wrote:
> Para ver un framework (casi no más que una librería C) que extiende
> increíblemente a C entrar a: https://github.com/CObjectSystem/COS

Muy interesante, pero parece un tanto desatendido. Probé compilarlo en
un Debian 9 (gcc 6.3.0) y no pude.
--

Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
Unidad Técnica Sistemas Inteligentes Av. General Paz 5445
Tel: (+54 11) 4724 6300 ext. 6919 San Martín - B1650KNA
FAX: (+54 11) 4754 5194 Buenos Aires * Argentina

[Jonathan Marino]

Qué raro,

Sí, lamentablemente no ganó la suficiente popularidad (otros lenguajes muchas veces tienen millones de dólares para publicidad), pero si te fijas hay commits de hace algunos días y un fork con un chico trabajando. A mí personalmente me gustaría involucrarme con el proyecto.

Quizás si le escribis a Laurent Deniau seguramente te responda, yo me mensajie un par de veces con él.

Dejo también un framework que él hizo basado en el modelo de objetos de C++ : http://ldeniau.web.cern.ch/ldeniau/html/oopc/oopc.html

Y uno que me gusta más para embebidos: http://ooc-coding.sourceforge.net/

Saludos!

[Salvador Eduardo Tropea]

Hola!

On 08/04/18 16:20, Jonathan Marino wrote:
> Qué raro,
> Sí, lamentablemente no ganó la suficiente popularidad (otros lenguajes
> muchas veces tienen millones de dólares para publicidad), pero si te
> fijas hay commits de hace algunos días y un fork con un chico trabajando.

Cloné el fork y lo pude compilar.
Para que no me putee el gcc agregué -Wno-unused-local-typedefs
-Wno-unused-const-variable

Voy a ver si ahora lo puedo ver un poco.

Saludos, Salvador

> A mí personalmente me gustaría involucrarme con el proyecto.
> Quizás si le escribis a Laurent Deniau seguramente te responda, yo me
> mensajie un par de veces con él.
>
> Dejo también un framework que él hizo basado en el modelo de objetos
> de C++ : http://ldeniau.web.cern.ch/ldeniau/html/oopc/oopc.html
>
> Y uno que me gusta más para embebidos: http://ooc-coding.sourceforge.net/
>
> Saludos!
>
>
> El jueves, 5 de abril de 2018, 13:34:58 (UTC-3), set escribió:
>
> On 05/04/18 05:37, Jonathan Marino wrote:
> > Para ver un framework (casi no más que una librería C) que extiende
> > increíblemente a C entrar a:
> https://github.com/CObjectSystem/COS
> <https://github.com/CObjectSystem/COS>
>
> Muy interesante, pero parece un tanto desatendido. Probé
> compilarlo en
> un Debian 9 (gcc 6.3.0) y no pude.
> --
>
> Ing. Salvador Eduardo Tropea http://utic.inti.gob.ar/
> INTI - Micro y Nanoelectrónica (CMNB) http://www.inti.gob.ar/
> Unidad Técnica Sistemas Inteligentes  Av. General Paz 5445
> Tel: (+54 11) 4724 6300 ext. 6919     San Martín - B1650KNA
> FAX: (+54 11) 4754 5194               Buenos Aires * Argentina
>
>
>
>

> --
> -- Recibiste este mensaje porque estás suscripto al Grupo Google
> Embebidos32. Para postear en este grupo, escribe un email a
> embeb...@googlegroups.com. Para des-suscribirte, envía un email a
> embebidos32...@googlegroups.com. Para más opciones, visita el
> sitio del grupo en https://groups.google.com/d/forum/embebidos32?hl=es
> ---
> Has recibido este mensaje porque estás suscrito al grupo "Embebidos32"
> de Grupos de Google.
> Para cancelar la suscripción a este grupo y dejar de recibir sus
> mensajes, envía un correo electrónico a
> embebidos32...@googlegroups.com

> <mailto:embebidos32...@googlegroups.com>.

> Para acceder a más opciones, visita https://groups.google.com/d/optout.

[Ivan Castellucci Vidal]

On Thursday, March 1, 2018 at 2:16:11 PM UTC-3, Bone wrote:

Buenas a todos, 

Queria reunir opiniones respecto de porque en el ambito de sistemas embebidos se sigue prefiriendo el uso de C sobre C++ en general. En los ambitos en los que ustedes suelen trabajar, cuales son las principales razones (si las hay): Falta de soporte por parte de los toolchains? C++ es muy complicado? C ofrece mejor control? Hay mas programadores disponibles que sepan sobre ARM, arquitectura de micros y bajo nivel que solo saben C y no tanto C++?

Espero sus opiniones!

Saludos!

Despues de leer todo el thread me gustaria agregar algunas opiniones personales ya que hace tiempo me vengo planteando C o C++:

1) En primer lugar hay mas conocimiento de librerias de fabricantes en C que en C++. Esto termina generando un efecto Bola de Nieve donde los fabricantes ven mas popularidad en sus versiones C, por lo tanto dan mas soporte y esto genera mas popularidad, etc.
No digo que esto pase en todos los casos, pero observo esa tendencia. No veo un motivo fuerte para decir C++ o C en este caso, pero me da la sensacion de que adoptar C++ es nadar contra la corriente y que pueden estallar bugs (por falta de soporte) cuando menos lo imaginemos a comparacion de quedarnos con C que sabemos que probablemente sea un codigo mas maduro.

2) Manteniendo la metafora del tiro en el pie, es cierto que C++ ofrece muchas herramientas utiles para evitar dispararse a uno mismo, pero teniendo en cuenta que los cursos que cubren C++ en carreras de electrónica lo hacen al estilo "existe C++, esta bueno y usa la palabra clave class" muchas de esas herramientas quedan escondidas a los ojos de los electronicos y por lo tanto, volviendo a la analogia del tiro en el pie, el arma esta sin seguro, cargada y el gatillo se puede activar al volar una mosca.
En mi caso, me inclino por aprender mas de C++ ya que es una herramienta y considero que mientras mas herramientas tenga y mas opciones pueda evaluar, mas completo va a ser mi entendimiento del problema al que me enfrente, supongo que es el caso de muchos aca pero no todos son asi y muchos de nuestros colegas, involucrados en proyectos con nosotros pueden ser de los que piensan "una vez lo use y no funciono, asi que para mi no funciona".

3) Hay algo de lo que nadie hablo en profundidad y es el debugging. Aca no hablo desde la experiencia y me gustaria que quienes la tengan me ilustren un poco, pero en C, siendo un lenguaje bastante minimalista es facil con un poco de GDB analizar casi la totalidad del programa.
Es asi también con C++? Mi sensacion (ojala me equivoque) es que al utilizar templates, lambdas, metaprogramacion, funciones virtuales, etc el debugging se va complicando.

Felíz sabado!