Programación C/C++

[Juan Carlos Suarez Baron]

Hola a todos. 

Alguno de ustedes tiene algún libro o sitio web para estudiar y aprender programación con C/C++?

Gracias por su atención.

--

Atentamente,
Juan Carlos Suárez Barón

[Fernando Rodríguez Brizuela]

Este sitio me resulta particularmente interesante

http://www.cplusplus.com/doc/tutorial/

Slds

Fernando L. Rodríguez Brizuela -

--
-- 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 anular 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.

[martin ribelotta]

Personalmente me gustan los tutoriales interactivos:

http://www.learn-c.org/

Aunque no es el unico y es bastante basico, es una buena forma de amoldarce al lenguaje rapidamente.

Para algo mas hardcode, recomiendo los dos volumenes de Thinking in C++, preferiblemente su verción inglesa aunque los links que pongo son de la verción en castellano:

http://arco.esi.uclm.es/~david.villa/pensar_en_C++/pensar_en_cpp-vol1.pdf

http://arco.esi.uclm.es/~david.villa/pensar_en_C++/pensar_en_cpp-vol2.pdf

El 20 de agosto de 2014, 19:57, Juan Carlos Suarez Baron <jsuare...@gmail.com> escribió:

--

[Abel Bortolameotti]

este esta muy bueno.

http://www.minidosis.org/#/

--
Abel Alejandro Bortolameotti

[Sebastián Zaffarano]

Si estás empezando de cero, altamente recomendable "The C programming Language", de Kernighan y Ritchie.  Una joyita.  

Por C++, antes de comenzar te diría que leas algo de programación orientada a objetos, como para manejar conceptos, luego Thinking in C++, que ya nombraron más arriba, es un excelente libro.

Saludos.

Sebastián

[lucio martinez]

Hay un autor que se llama Herber Shildt. Este tipo tiene varios libros pero particularmente tiene un conjunto de cuatro libros que se llaman

1)- Guía de autoenseñanza de C

2)- Manual de referencia  de C

3)- Guía de autoenseñanza de C++

4)- Manual de referencia  de C++

los cuatro son a mi entender muy buenos. mis recomendaciones son:

 

Si queres algo básico

C arrancar por el 1

C++ arrancar por el 3

 

Si queres algo más avanzado

C arrancar por el 2

C++ arrancar por el 4

 

tene en cuenta que si queres usar C++ es porque queres programar orientado a objetos y C++ no es un lenguaje puro desde ese punto de vista.

 

como dice Sebastián el libro de Kernighan y Ritchie es muy bueno, pero quizá no sea para arrancar

también si queres profundizar en C++ podes buscar el libro de STROUSTRUP, que es como el KyR pero de C++

este libro es bastante duro.

los libros de Herber Shildt no creo que se editen mas, pero los podes conseguir en Bs.As. Books seguramente

el libro de Stroustrup se sigue editando

Después hay cosas más breves como la guía BEEJ pero de C, no la use nunca pero use la de Socket y la de IPC y eran muy practicas

http://beej.us/guide/bgc/output/print/bgc_A4.pdf

 

 

saludos

Lucio

[fabian juarez]

Hola a todos quisiera saber si me pueden recomendar un libro o pagina donde se explique y si es posible en español la programacion en c para microcontroladores freescale mediante codewarrior. Desde ya muchas gracias por todo

[Alejandro J. Formichelli]

Juan Carlos, la respuesta depende mucho del conocimiento/nivel que tengas sobre programación.

Si tu nivel es inicial o muy básico, tal vez la mejor opción sea:

Programming - Principles and Practice Using C++
Bjarne Stroustrup  - (2nd Ed 2014 - Pearson Education)
ISBN 978-0-321-99278-9

Si ya tenés experiencia en programación en C tal vez te sirva:

Moving from C to C++
Arunesh Goyal (2013 - Apress)
ISBN 978-1-4302-6094-3

Con cualquier de esos dos tenés para entretenerte durante varios meses (siendo optimista).

Como complemento te paso dos links para que puedas ver otras opciones

Libros sobre C
http://stackoverflow.com/questions/562303/the-definitive-c-book-guide-and-list

Libros sobre C++
http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list

Ambas listas incluyen libros clasificados de acuerdo al nivel del lector

Espero que te sirvan y contanos cómo te fue para que sirva de referencia a otros que están en el mismo camino.

Saludos,

Alejandro

- 
Ing. Alejandro J. Formichelli

INTI - Electrónica e Informática   www.inti.gob.ar
Av. Gral Paz 5445 - Ed. 42
(B1650WAB) SAN MARTIN              (54-11-)   4724-6200/6300/6400
Provincia de Buenos Aires          (ext 6371) int 6371
República 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 anular 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.

-

[Sebastián Zaffarano]

Sin ánimo de buscar generar polémica, dejo un link con la opinión de Linus Torvalds sobre C++ cuando le preguntaron por qué programó git en C puro.  

Sería bueno conocer qué experiencias tienen quienes en el grupo programan microcontroladores en C++.

Saludos,

Sebastián

[Matias Romanin]

Alguien conoce libros de C para pogramar microcontroladores/sistemas embebidos?

[Ricardo Medel]

No tengo idea del tema... pero si sabés inglés quizás estos de O'Reilly te puedan servir:

Programming Embedded Systems in C and C++ (1999), creo que se puede conseguir gratis online.
http://shop.oreilly.com/product/9781565923546.do

Programming Embedded Systems, 2nd Edition

With C and GNU Development Tools (2006)
http://shop.oreilly.com/product/9780596009830.do

Ricardo

[martin ribelotta]

Libros no se, pero que hay mucho escrito sobre esto si que lo hay:

http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_San_Jose_98_401_paper.pdf

http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_SF_02_465_paper.pdf

http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_SF_02_405_&_445_paper.pdf

http://www.open-std.org/jtc1/sc22/wg21/docs/ESC_Boston_01_304_paper.pdf

http://www.embedded.com/design/programming-languages-and-tools/4424383/A-guide-to-C--for-C-programmers

http://www.eetindia.co.in/ARTICLES/1998FEB/PDF/EEIOL_1998FEB02_EMS_TA.pdf

El 21 de agosto de 2014, 11:05, Matias Romanin <matias....@gmail.com> escribió:

[martin ribelotta]

También seria bueno recordar que Linus le encanta ser full-troll en ABSOLUTAMENTE TODO!!!!

La decisión de usar C en vez de C++ en git es porque a Linus sabe que la dificultad de escribir código medianamente independiente de la arquitectura en C++ es bastante mayor para muchas aplicaciones simples (si, git es SIMPLE en cuanto a complejidad esencial). Del otro lado, hacer un escritorio en C (diseño meramente POO) es una real estupidez. Similar a hacer un kernel en C++ (notar que ambos diseños son POO en cierta medida)

Hay que tener cuidado con las opiniones de Linus y mantenerlas en el contexto en las que las escupe porque sino podemos defender bestialidades como gnome con el mismo principio que los defensores de un kernel C++.

Entonces ¿C++ en embebidos?

Mi respuesta es:

Para variar, depende. Aunque de que... eso es un tema que da para un hilo distinto (y un epic-flamewar)

El 21 de agosto de 2014, 10:43, Sebastián Zaffarano <se...@zaffarano.com.ar> escribió:

[Sebastián Zaffarano]

Si, totalmente de acuerdo a cómo recibir las opiniones de Linus.  

Me interesan las opiniones sobre C++ en embebidos porque hasta el momento todo lo que hice (que por otro lado son proyectos de fin de semana) fue en ansi C y aún no encuentro motivos para utilizar C++ para programar un microcontrolador.  

En mi profesion programo OO en otros lenguajes (java, scala, ruby) y la verdad que no me siento cómodo para nada con C++, más allá del código que genera el compilador, y qué tan optimo pueda resultar.

Saludos, y perdón por el OT, ya que desvirtué el thread de Juan Carlos.

Sebastián

[Fernando Cacciola]

Hola Juan Carlos,

2014-08-20 19:57 GMT-03:00 Juan Carlos Suarez Baron <jsuare...@gmail.com>:

Hola a todos. 

Alguno de ustedes tiene algún libro o sitio web para estudiar y aprender programación con C/C++?

Antes que nada te recomiendo que decidas si quieres aprender C o C++. Aunque tengan algunas cosas en común, son lenguajes distintos y se utilizan de forma distinta.

Cuál es el más adecuado para vos depende de muchas cosas.. sin mayores detalles no puede hacerte una recomendación.

Saludos

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

[Pedro Martos]

Hola, mi aporte al epic-flamewar:

El poder programar sistemas embebidos con un lenguaje mas abstracto (c++/java/python/Arduino/etc) depende de los requerimientos no funcionales del sistema, generalmente el consumo, la performance y el espacio en memoria (memory footprint). 

Si tus requerimientos no funcionales te permiten utilizar un lenguaje mas abstracto, probablemente tardes menos en desarrollar el software y el mismo sea mas mantenible. Si no podes cumplir los requerimientos no funcionales, entonces tenes que utilizar lenguajes que te permitan un control mas fino del hardware, del uso de la memoria y del flujo de ejecucion del programa (lo opuesto a la abstraccion), hasta llegar a C o en el peor de los casos, al assembler.

En resumen, como dijo Martin, depende... y generalmente depende de los requerimientos no funcionales del sistema 

cordialmente,

Pedro

El 21 de agosto de 2014, 11:59, martin ribelotta<martinr...@gmail.com> escribió:

También seria bueno recordar que Linus le encanta ser full-troll en ABSOLUTAMENTE TODO!!!!

La decisión de usar C en vez de C++ en git es porque a Linus sabe que la dificultad de escribir código medianamente independiente de la arquitectura en C++ es bastante mayor para muchas aplicaciones simples (si, git es SIMPLE en cuanto a complejidad esencial). Del otro lado, hacer un escritorio en C (diseño meramente POO) es una real estupidez. Similar a hacer un kernel en C++ (notar que ambos diseños son POO en cierta medida)

Hay que tener cuidado con las opiniones de Linus y mantenerlas en el contexto en las que las escupe porque sino podemos defender bestialidades como gnome con el mismo principio que los defensores de un kernel C++.

Entonces ¿C++ en embebidos?

Mi respuesta es:

Para variar, depende. Aunque de que... eso es un tema que da para un hilo distinto (y un epic-flamewar)

--
cordiales saludos,

Pedro Ignacio Martos

pma...@fi.uba.ar / pima...@gmail.com

http://web.fi.uba.ar/~pmartos

[martin ribelotta]

Primero que nada, vamos a poner algunas cosas facticas en claro:

* Mentira que C++ requiera memoria dinamica. operator new y delete pueden sobrecargarse para que no retornen nada o sean puntos de trap al ser usadas. Lo unico que requiere memoria dinamica son las librerias STL las cuales estan fuera de discución dentro del ambito embmebido (salvo que alguien logre una implementación determinista en el uso de memoria)

* RTTI es parte de C++ desde hace bastante poco, generalmente se puede desactivar sin ningun problema con el consiguiente ahorro de recursos en runtime.

* Las excepciones son otro tanto, no solo se puede desactivar para que el compilador de error al tratarla de usar, sino que simplemente con NO USARLAS ya no ocupa lugar en el runtime.

* En experiencia propia, todo lo anterior incluso activado, ocupa en un Cortex-M4 usando gcc 4.7 y los stubs correspondientes para evitar codigo innecesario (manteniendo el 100% de la funcionalidad) apenas 16K de flash y algunos bytes mas de RAM (menos de 64 pero no recuerdo el numero justo ahora).

Por otro lado, las ventajas (técnicas) que yo veo de C++ sobre C en sistemas embebidos son:

* Seguridad de tipos: C++ es mas estricto en los castings y permite mayor expresividad a la hora de manejar y definir tipos. Muchas de esas mejoras están en C99 y como extenciones en otros C, pero C++ las incorpora oficialmente al lenguaje.

* Eficiencia: C++ puede generar codigo mas eficiente para depende que tareas:

const int MAX_COUNT = 10;

...

for(int i=0; i<MAX_COUNT; i++) { ... }

Genera mejor codigo que su equivalente en C, ya que, MAX_COUNT no está obligado a aparecer en el lado del linker como entidad referenciable (salvo que se lo referencie en alguna parte del codigo). C estandar OBLIGA a que MAX_COUNT aparesca como simbolo referenciable (otra cosa es lo que pueda optimizar el linker)

C++11 extiende esto todavia mas permitiendonos definir funciones constantes (resolubles en tiempo de compilación) con constexpr, de forma que si escribimos por accidente codigo que el compilador no puede resolver mientras compila, fallará con un error.

Eso nos lleva a lo siguiente:

* Seguridad en la codificación: C++ permite detectar muchos mas errores que C. Solo pensemos en el preprocesador de C versus los templates de C++ (que no tienen porque generar codigo mas alla de una simple constante). Ok, los errores de templates pueden ser una verdadera garcha pero eso podemos atribuirlo a gcc, clang por ejemplo, es mucho mas limpio en sus mensajes de error.

Como muestra, un boto:

Esta libreria https://github.com/martinribelotta/cm3pp_lib_devel/blob/master/Source/cxx/GPIO.h implementa manejo de puertos en C++ para stm32f4. La clase PinConfig jamas genera codigo ejecutable, simplemente se usa así:

PortB.enable();

PortB.init(GPIO::PinConfig(11, GPIO::Speed50Mhz, GPIO::OutPP)

+ GPIO::PinConfig(12, GPIO::Speed50Mhz, GPIO::OutPP)

+ GPIO::PinConfig(2, GPIO::SpeedIn, GPIO::InPullUp));

Todo el codigo de PortB.init( .... ) se transforma en una constante, la cual es cargada a la posición de memoria que define las caracteristicas del puerto.

El codigo del fabricante en C ocupa al rededor de 100 bytes para lo mismo, versus el codigo en C++ bien pensado que ocupa 8 bytes para la carga de la constante a registro y otros 8 para el store en la posicion de memoria correspondiente.

* C++ provee manejo de objetos con sintaxis mantenible. No nos engañemos, cualquier diseño grande termina usando objetos lo quieramos o no, de hecho cosas como las FSM, las FIFO o cualquier entidad procedural que maneje datos son objetos. C no ayuda demaciado en el manejo de objetos ni en su checkeo de tipos.

No es que en C no se puedan manejar objetos, pero requiere ciertos cuidados que no son faciles de detectar incluso para un statick checker (de hecho, muchas practicas legales de POO en C, son contraproducentes para los static checkers)

Como todo, cualquiera de los puntos que menciono arriba pueden ser buenos o malos dependiendo del contexto, pero son como minimo, una herramienta que tenemos que conocer a la hora de plantear soluciones.

Cuando usaria C++?????

* Cuando mi cliente requiera un API simple y con seguridad de tipos y contextos. Si el cliente debe tener en cuenta muchas pre/post condiciones para la operación de mi codigo, lo mas probable es que en algun momento falle en algo y el mecanismo que yo hice se rompa de forma extraña y posiblemente, poco intuitiva.

* Cuando requiera un manejo de objetos con sintaxis segura. Los objetos están ahi, y es una forma inconciente de desarrollar un sistema sea cual sea (de hecho, muchos psicologos sostienen que es una manera sistematica de resolucion de problemas, lo cual no puedo ni afirmar ni contrariar ya que no es mi area)

* Cuando requiera resolución de tipos y codigo en tiempo de compilación para mejorar el codigo objeto generado. Esto es especialmente util para sistemas donde la memoria es un problema a abordar y el codigo requiere mucha resolución automatica (y mucha de esa resolución se puede hacer en tiempo de compilación)

Bueno, hasta aqui, mis 2c

[Ricardo Malerba]

Coincido en muchas cosas de las que comento Martín, haciendo un uso restringido de las características de C ++ se puede adecuar bien a un embebido, tanto en footprint de memorias como en tiempo de ejecución. La única contra que tiene el uso de C++ es que olvidate de compiladores gratuitos para C++ salvo GCC y algún que otro todos los fabricantes te cobran para usarlos. Y voy a realizar un crítica constructiva, no todo en la vida es ARM y gcc. Si queres aprender volcate a C plano, te puedo servir para muchas plataformas. 

Saludos !

Ricardo Malerba

[Fernando Cacciola]

Hola Martín,

Lógicamente estoy de acuerdo con lo que decís, pero quería comentar un par de puntos:

2014-08-21 15:47 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Primero que nada, vamos a poner algunas cosas facticas en claro:

* Mentira que C++ requiera memoria dinamica. operator new y delete pueden sobrecargarse para que no retornen nada o sean puntos de trap al ser usadas.

Por otro lado, por default usa el heap y uno podría argumentar que C++ en embebidos requiere mayor expertise por parte del programador que en C.

 

Lo unico que requiere memoria dinamica son las librerias STL las cuales estan fuera de discución dentro del ambito embmebido (salvo que alguien logre una implementación determinista en el uso de memoria)

Justamente en *estos dìas* hay un grupo de trabajo en formac ión dentro del comité de estandarización del C++ tratando el tema embedded, y uno de los puntos es allocator para la STL que permita evitar el uso del heap.

* RTTI es parte de C++ desde hace bastante poco, generalmente se puede desactivar sin ningun problema con el consiguiente ahorro de recursos en runtime.

* Las excepciones son otro tanto, no solo se puede desactivar para que el compilador de error al tratarla de usar, sino que simplemente con NO USARLAS ya no ocupa lugar en el runtime.

En realidad, hay un footprint aún cuando no las uses (e incluso usando -no_exception en gcc). Es una de las cosas que se están tratando.

El Viernes pasado en el SASE, Daniel Gustson hizo una presentación muy interesante donde explicó como sacarse todo ese foorprint de encima en el caso de gcc. No es nada que uno vaya a saber naturalmente (y dudo que en google), pero estos chicos de Taller lo hicieron y Daniel puede explicarlo acá en la lista llegado el caso.
 

* En experiencia propia, todo lo anterior incluso activado, ocupa en un Cortex-M4 usando gcc 4.7 y los stubs correspondientes para evitar codigo innecesario (manteniendo el 100% de la funcionalidad) apenas 16K de flash y algunos bytes mas de RAM (menos de 64 pero no recuerdo el numero justo ahora).

Totalmente. Y para los casos donde esos 16K es prohibitivo, hay cosas puntuales que se pueden hacer (como lo que expuso Daniel en el SASE)

Por otro lado, las ventajas (técnicas) que yo veo de C++ sobre C en sistemas embebidos son:

* Seguridad de tipos: C++ es mas estricto en los castings y permite mayor expresividad a la hora de manejar y definir tipos. Muchas de esas mejoras están en C99 y como extenciones en otros C, pero C++ las incorpora oficialmente al lenguaje.

* Eficiencia: C++ puede generar codigo mas eficiente para depende que tareas:

const int MAX_COUNT = 10;

...

for(int i=0; i<MAX_COUNT; i++) { ... }

Genera mejor codigo que su equivalente en C, ya que, MAX_COUNT no está obligado a aparecer en el lado del linker como entidad referenciable (salvo que se lo referencie en alguna parte del codigo). C estandar OBLIGA a que MAX_COUNT aparesca como simbolo referenciable (otra cosa es lo que pueda optimizar el linker)

C++11 extiende esto todavia mas permitiendonos definir funciones constantes (resolubles en tiempo de compilación) con constexpr, de forma que si escribimos por accidente codigo que el compilador no puede resolver mientras compila, fallará con un error.

No solo eso... las funciones inline (de C++ de siempre) generan más codigo pero la diff de performance puede ser brutal.

Mi único reparo en usar C++ no es técnico sino "social": una empresa tiene que decidir entre uno y otro sopesándo la mayor o menor facilidad para encontrar recursos idóneos. En mi empresa por ejemplo, tenemos un programador "C++" es en realidad un programador C. Si no ocurriera que yo personamente me puedo ocupar de entrenarlo adecuadamente, tal vez (solo tal vez) usaría C.

[Mariano Cerdeiro]

Hola Todos,

agrego mi opinion. Ningun lenguaje se puede usar para sistemas críticos/embebidos sin adaptarlo a las necesidades. Por eso existen coding guidelines y documentos como MISRA (http://caxapa.ru/thumbs/468328/misra-c-2004.pdf) o de la NASA: http://homepages.inf.ed.ac.uk/dts/pm/Papers/nasa-c-style.pdf.

Además existen tools de static code checkers que evitan justamente estos dilemas ya que le dicen al programador que hizo mal. ya sea en C como en C++. Evitando errores típicos por entender que el compilador hace algo cuando en realidad hace otra cosa... :)

El tema de encontrar personal que sepa, en mi entender es igual de dificil. Lo que si pasa es que mucha más gente cree que sabe C y son muchos menos los que creen que saben C++. Sin embargo saber C bien requiere muchos anios de laburo y práctica. Ahora no saber C++ es rapido ya que si no sabes lo que es un objeto decis que NO. En cambio saber C todos te deicen que si. Luego preguntas cual es la diferencia entre:

typedef int * const foo;

y

typedef int const * foo;

y ya te miran con cara de loco y si preguntas por integer promotion salen corriendo... y son cosas BÁSICAS para programar en sistemas embebidos multi plataforma.

Saludos.
Mariano.-

--

[Guillermo Villamayor]

Leí el artículo y tiene algo de razón, el c++ es un lenguaje sucio (esta expresión no es mía) porque permite mezclar c con c++. Esto si uno es un programador avezado puede ser bueno, sino habría que ver. La principal diferencia no son las librerías que hay disponibles, sino que el C es un lenguaje estructurado y el C++ es un lenguaje orientado a objetos. Entonces si uno hace un programa estructurado con algunas librerías de C++, no está haciendo un programa orientado a objetos. La estructura del software es muy distinta. Yo leí en una página muy importante de C++ que una clase es una estructura con funciones, eso es una locura. Es lo mismo que decir que un auto es una carreta con motor.

La programación orientada a objetos permitió, sin aportar mucho nuevo, hacer sistemas cada vez mas grande. A cambio de eso se perdió el control cercano del hardware que si conservan lenguajes como el C y que es muy útil a la hora de integrar un software en un microprocesador. Si uno hace un programa de 200 o 500 líneas creo que el C es muy bueno si el programa es mas grande se puede empezar a poner espeso. Si el sistema embebido tiene cargado un sistema operativo yo empezaría a pensar en otras cosas porque a veces veo que tratan de cargar librerías para poder hacer gráficos o manejar dispositivos, en general son librerías que no están pensadas para funcionar todas juntas y queda un Frankestein medio feo. Además si uno pretende hacer algo un poco grande manejando byte a byte la memoria, volvemos cuando el universo se empiece a contraer a ver si terminó.

De todas formas el C me parece muy bueno para muchos desarrollos y por alguna razón los fabricantes de microprocesadores siempre proveen algun API para desarrollo.

Todo depende de lo que le guste al desarrollador, como se sienta mas cómodo y lo que mas sepa.        

 

Sebastián

 

Sebastián

--
-- 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 mailto:embebidos32%2Bunsu...@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 anular 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 mailto:embebidos32%2Bunsu...@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 anular 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 mailto:embebidos32%2Bunsu...@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 anular 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 mailto:embebidos32%2Bunsu...@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 anular 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 mailto:embebidos32%2Bunsu...@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 anular 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.

 

--
Ricardo Malerba

[martin ribelotta]

Respondo entre lineas :-)

El 21 de agosto de 2014, 16:12, Fernando Cacciola <fernando...@gmail.com> escribió:

Hola Martín,

Lógicamente estoy de acuerdo con lo que decís, pero quería comentar un par de puntos:

2014-08-21 15:47 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Primero que nada, vamos a poner algunas cosas facticas en claro:

* Mentira que C++ requiera memoria dinamica. operator new y delete pueden sobrecargarse para que no retornen nada o sean puntos de trap al ser usadas.

Por otro lado, por default usa el heap y uno podría argumentar que C++ en embebidos requiere mayor expertise por parte del programador que en C.

 

Si no hay runtime de SSOO (tipico caso bare metal) new y delete fallan estrepitosamente al linkear porque refieren a malloc y free o a sbrk (peor todavia). Asi que la unica manera de tener algo andando de eso es sobrecargarlas con algun stub.

Por logica, y agregando a lo que dice Mariano en otro mail, nada salva a un programador de hacer idioteces :-D

 

Lo unico que requiere memoria dinamica son las librerias STL las cuales estan fuera de discución dentro del ambito embmebido (salvo que alguien logre una implementación determinista en el uso de memoria)

Justamente en *estos dìas* hay un grupo de trabajo en formac ión dentro del comité de estandarización del C++ tratando el tema embedded, y uno de los puntos es allocator para la STL que permita evitar el uso del heap.

Excelente noticia!!!! De todas formas, yo lo usaria con extremo cuidado, porque los templates en general, permiten esconder cosas muy feas como news y deletes extraños o mucha generación de codigo duplicada... Siempre hay que usar las cosas con criterio, por desgracia, no siempre estan tan a la vista esos criterios. Ahi, C tiene la ventaja a la cual hace referencia Linus que se puede resumir en una frace del gran filosofo, numerologo, astrologo, limpiador de baño y vendedor de productos Avon "Anonimo":

"En C es muy fácil pegarse un tiro en la pierna, en C++ es mucho mas difícil, pero cuando ocurre, te la vuelas"

 

* RTTI es parte de C++ desde hace bastante poco, generalmente se puede desactivar sin ningun problema con el consiguiente ahorro de recursos en runtime.

* Las excepciones son otro tanto, no solo se puede desactivar para que el compilador de error al tratarla de usar, sino que simplemente con NO USARLAS ya no ocupa lugar en el runtime.

En realidad, hay un footprint aún cuando no las uses (e incluso usando -no_exception en gcc). Es una de las cosas que se están tratando.

El Viernes pasado en el SASE, Daniel Gustson hizo una presentación muy interesante donde explicó como sacarse todo ese foorprint de encima en el caso de gcc. No es nada que uno vaya a saber naturalmente (y dudo que en google), pero estos chicos de Taller lo hicieron y Daniel puede explicarlo acá en la lista llegado el caso.

Fuck! Me lo perdí, si sos tan amable, indicame cual era la charla así despues busco las presentaciones en la pagina del SASE...

En su momento, logre (con gcc) tener andando C++ sin consumir mas de lo que el mismo programa en C haría, pero esto puede no ser cierto para otros compiladores o versiones del mismo o runtimes o fases de la luna jajajaja.

 

 

* En experiencia propia, todo lo anterior incluso activado, ocupa en un Cortex-M4 usando gcc 4.7 y los stubs correspondientes para evitar codigo innecesario (manteniendo el 100% de la funcionalidad) apenas 16K de flash y algunos bytes mas de RAM (menos de 64 pero no recuerdo el numero justo ahora).

Totalmente. Y para los casos donde esos 16K es prohibitivo, hay cosas puntuales que se pueden hacer (como lo que expuso Daniel en el SASE)

Por otro lado, las ventajas (técnicas) que yo veo de C++ sobre C en sistemas embebidos son:

* Seguridad de tipos: C++ es mas estricto en los castings y permite mayor expresividad a la hora de manejar y definir tipos. Muchas de esas mejoras están en C99 y como extenciones en otros C, pero C++ las incorpora oficialmente al lenguaje.

* Eficiencia: C++ puede generar codigo mas eficiente para depende que tareas:

const int MAX_COUNT = 10;

...

for(int i=0; i<MAX_COUNT; i++) { ... }

Genera mejor codigo que su equivalente en C, ya que, MAX_COUNT no está obligado a aparecer en el lado del linker como entidad referenciable (salvo que se lo referencie en alguna parte del codigo). C estandar OBLIGA a que MAX_COUNT aparesca como simbolo referenciable (otra cosa es lo que pueda optimizar el linker)

C++11 extiende esto todavia mas permitiendonos definir funciones constantes (resolubles en tiempo de compilación) con constexpr, de forma que si escribimos por accidente codigo que el compilador no puede resolver mientras compila, fallará con un error.

No solo eso... las funciones inline (de C++ de siempre) generan más codigo pero la diff de performance puede ser brutal.

Eso puede o no ser cierto, a veces (cuando la funcion hace cosas muy simples, como leer un registro o calcular un valor) puede ser mas constoso crear y destruir el marco de llamada que ejecutar el codigo en si inline (tanto en codigo como en tiempo de ejecución) aunque, para casos normales, lo mas comun es lo que decis vos

 

Mi único reparo en usar C++ no es técnico sino "social": una empresa tiene que decidir entre uno y otro sopesándo la mayor o menor facilidad para encontrar recursos idóneos. En mi empresa por ejemplo, tenemos un programador "C++" es en realidad un programador C. Si no ocurriera que yo personamente me puedo ocupar de entrenarlo adecuadamente, tal vez (solo tal vez) usaría C.

Y eso es lo que, normalmente, define el uso de cualquier tecnologia:

* ¿Cuanta gente lo sabe usar?

* ¿Que tan productivos pueden ser para tal problema mis recursos humanos?

* ¿Cuanto le lleva a mi gente adaptarse al conjunto de herramientas?

* ¿Cuanto cuesta en dinero y en horas/hombre esas herramientas?

* ¿Estoy seguro de poder cumplir con los requerimientos con esas herramientas o es un salvavidas de plomo?

Normalmente a los ingenieros tekkies (como yo) no nos gusta hacernos estas preguntas, pero generalmente es lo que define el 90% del problema.

 

Saludos

--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com

--

[Matias Vara]

Hola, queria solamente realizar un pequeño aporte al hilo. Me da la impresion que para diseño de sistema embebidos el desarrollo se esta moviendo a lenguages más abstractos basados en modelos computacionales (Domain Specific Modeling Language). Luego la fase implementiva  (C, C++, etc) es generada automaticamente. Asi, por un lado se pierde expresividad, porque un DSML es justamente un lenguage hecho a medida, para ganar en verificación o predicibilidad que esta limitada cuando se usa un lenguage de proposito general como C, C++ etc. Por otro lado, también permite hacerse independiente de la implementación.

Saludos.      

--
MV

[Sebastián Zaffarano]

Martín, excelente tu explanación.  Muchas gracias por tomarte el tiempo de elaborarla con tal nivel de detalle.

Un saludo.

Sebastián

El 21 de agosto de 2014, 15:47, martin ribelotta<martinr...@gmail.com> escribió:

[Carlos Eduardo López Aldana]

Muy interesante todos los comentarios :) Da gusto que algunos temas sean tratados en esta lista de email así de esta manera...
Mi opinión sobre el FUTURO...:
Sin DUDAR y todo lleva, empuja, tira, etc. a PROGRAMAR COMO SE HACE EN UN PC...
Ya que antes con recursos limitados se optimizaba, ahora como los microcontroladores son mas baratos, tienen mas memoria, mas poder de calculo se esta abstrayendo cada vez mas....
En un futuro no muy lejano 3 lineas y programa echo.... :)
Saludos...

Carlos Eduardo López Aldana...

[Leandro Francucci]

Siguiendo con los conceptos de Mariano y Martín, una reflexión más.

Algo que preocupa es que la programación como tal, no depende exclusivamente de un lenguaje, ni mucho menos de una plataforma particular, muchas veces se piensa que conocer la sintáxis y sentencias de un lenguaje o acceder más o menos eficiente a los registros de un procesador es suficiente para programar sobre un embedded. Es justo donde se descuidan los conceptos fundamentales de la programación y que en definitiva hacen a la calidad del software (cumplir los requerimientos, comprensibilidad, buena documentación, transportabilidad, capacidad de mantenimiento, concisión, capacidad de prueba, confiabilidad, eficiencia, rendimiento, escalabilidad, flexibilidad, robustez, etc), independientemente del lenguaje empleado e inclusive si es o no embedded. Son pocos los libros y cursos que hacen hincapié de manera explícita en estos conceptos, y por lo general, uno los termina aprendiendo con mucha transpiración y esfuerzo. Y por si fuera poco, lamentablemente, muchos otros los ignoran.

Para mostrar a que me refiero:

Supongamos, dos equipos de desarrollo A y B, trabajan para lograr los mismos requerimientos funcionales, objetivos. El equipo A trabaja en favor de la calidad de software, pensando no sólo en cumplir los objetivos funcionales, sino también en que lo realizado pueda reutilizarse, sea fácil de mantener, sea legible, robusto, flexible, fácil de escalar, que permita con poco esfuerzo un cambio de plataforma, entre otras cuestiones que hacen a la calidad del software. Por otro lado, el equipo B, desconoce o ignora parte de las prácticas que aplica el equipo A, no obstante trabaja fuertemente en lograr los objetivos funcionales.

Al cabo de un tiempo, ambos equipos cumplen la totalidad de los requerimientos funcionales, desde el punto de vista de "caja negra" ambos resultados son parecidos y aceptables, inclusive en algunas cuestiones no funcionales, como performance, ocupación de memoria, etc. Una observación es que el equipo A, tardó bastante más tiempo en lograr el mismo resultado funcional que el contundente y eficaz equipo B.

Luego de un tiempo, a ambos equipos se les transmite la necesidad de realizar algunos cambios e incorporar nuevas funcionalidades, siendo alguna de estas de gran impacto, al menos en principio. El equipo B comienza su labor, como siempre, con gran esfuerzo, orientado al resultado inmediato, aunque durante el transcurso del cambio le surgen algunos problemas que no pensaba que pudieran surgir, ya que su solución estaba exactamente pensada al caso anterior. Por su parte, el equipo A, desarrolla los cambios y las nuevas funcionalidades, inclusive incorpora algunas mejoras, con poca transpiración y sobresalto, ya que rápidamente entregan la solución funcionando. Mientras tanto, el equipo B sigue con la lucha, hasta que luego de un gran esfuerzo, finalmente entrega la solución en un tiempo bastante mayor al equipo A.

Ahora, surge la necesidad de construir un nuevo producto, en el mismo dominio del sistema anterior, pero con ciertas diferencias funcionales y no funcionales, por ejemplo se pretende una nueva plataforma.

En cuyo caso, el equipo A realiza los cambios que necesita el sistema actual para lograr el nuevo producto, los cuales se implementan en un tiempo razonable, mucho menor al sistema anterior, y de forma segura. Mientras que el equipo B, con gran preocupación, piensa que es mejor comenzar todo de nuevo, ya que no es posible lograr un producto basado en el software anterior, o al menos en tiempo y forma, pero como es sumamente rápido y eficaz para resolver problemas, comienza el desarrollo desde "cero" tomando sólo algunas cuestiones del sistema anterior.

Y así siguiendo...

En definitiva, no sé si un equipo es mejor o peor que el otro, lo que si sé, es que son realmente diferentes...

LF

[Fernando Cacciola]

2014-08-21 17:19 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Respondo entre lineas :-)

El 21 de agosto de 2014, 16:12, Fernando Cacciola <fernando...@gmail.com> escribió:

Hola Martín,

Lógicamente estoy de acuerdo con lo que decís, pero quería comentar un par de puntos:

2014-08-21 15:47 GMT-03:00 martin ribelotta <martinr...@gmail.com>:

Primero que nada, vamos a poner algunas cosas facticas en claro:

* Mentira que C++ requiera memoria dinamica. operator new y delete pueden sobrecargarse para que no retornen nada o sean puntos de trap al ser usadas.

Por otro lado, por default usa el heap y uno podría argumentar que C++ en embebidos requiere mayor expertise por parte del programador que en C.

 

Si no hay runtime de SSOO (tipico caso bare metal) new y delete fallan estrepitosamente al linkear porque refieren a malloc y free o a sbrk (peor todavia). Asi que la unica manera de tener algo andando de eso es sobrecargarlas con algun stub.

Claro.

Pero podés tener un SO, digamos un RTOS, en cuyo caso, el heap está pero en realidad es mejor que no lo uses (muchas veces)
 

Por logica, y agregando a lo que dice Mariano en otro mail, nada salva a un programador de hacer idioteces :-D

 

:)
 

Lo unico que requiere memoria dinamica son las librerias STL las cuales estan fuera de discución dentro del ambito embmebido (salvo que alguien logre una implementación determinista en el uso de memoria)

Justamente en *estos dìas* hay un grupo de trabajo en formac ión dentro del comité de estandarización del C++ tratando el tema embedded, y uno de los puntos es allocator para la STL que permita evitar el uso del heap.

Excelente noticia!!!! De todas formas, yo lo usaria con extremo cuidado, porque los templates en general, permiten esconder cosas muy feas como news y deletes extraños o mucha generación de codigo duplicada... Siempre hay que usar las cosas con criterio, por desgracia, no siempre estan tan a la vista esos criterios.

Lógico.
Por otro lado, actualmente, en el mundo embeeded estas cosas "no se tocan", y va a estar bueno cuando eso no sea así y existan best practices de STL para este mundillo.
 

Ahi, C tiene la ventaja a la cual hace referencia Linus que se puede resumir en una frace del gran filosofo, numerologo, astrologo, limpiador de baño y vendedor de productos Avon "Anonimo":

"En C es muy fácil pegarse un tiro en la pierna, en C++ es mucho mas difícil, pero cuando ocurre, te la vuelas"

 

* RTTI es parte de C++ desde hace bastante poco, generalmente se puede desactivar sin ningun problema con el consiguiente ahorro de recursos en runtime.

* Las excepciones son otro tanto, no solo se puede desactivar para que el compilador de error al tratarla de usar, sino que simplemente con NO USARLAS ya no ocupa lugar en el runtime.

En realidad, hay un footprint aún cuando no las uses (e incluso usando -no_exception en gcc). Es una de las cosas que se están tratando.

El Viernes pasado en el SASE, Daniel Gustson hizo una presentación muy interesante donde explicó como sacarse todo ese foorprint de encima en el caso de gcc. No es nada que uno vaya a saber naturalmente (y dudo que en google), pero estos chicos de Taller lo hicieron y Daniel puede explicarlo acá en la lista llegado el caso.

Fuck! Me lo perdí, si sos tan amable, indicame cual era la charla así despues busco las presentaciones en la pagina del SASE...

"Desarrollo en C++ de aplic. embebidas p/plataformas con bajos recursos. Ing. D. Gutson (Taller Technologies)"

en el track de Software Embedido.

En su momento, logre (con gcc) tener andando C++ sin consumir mas de lo que el mismo programa en C haría, pero esto puede no ser cierto para otros compiladores o versiones del mismo o runtimes o fases de la luna jajajaja.

Tal cual.
 

 

 

* En experiencia propia, todo lo anterior incluso activado, ocupa en un Cortex-M4 usando gcc 4.7 y los stubs correspondientes para evitar codigo innecesario (manteniendo el 100% de la funcionalidad) apenas 16K de flash y algunos bytes mas de RAM (menos de 64 pero no recuerdo el numero justo ahora).

Totalmente. Y para los casos donde esos 16K es prohibitivo, hay cosas puntuales que se pueden hacer (como lo que expuso Daniel en el SASE)

Por otro lado, las ventajas (técnicas) que yo veo de C++ sobre C en sistemas embebidos son:

* Seguridad de tipos: C++ es mas estricto en los castings y permite mayor expresividad a la hora de manejar y definir tipos. Muchas de esas mejoras están en C99 y como extenciones en otros C, pero C++ las incorpora oficialmente al lenguaje.

* Eficiencia: C++ puede generar codigo mas eficiente para depende que tareas:

const int MAX_COUNT = 10;

...

for(int i=0; i<MAX_COUNT; i++) { ... }

Genera mejor codigo que su equivalente en C, ya que, MAX_COUNT no está obligado a aparecer en el lado del linker como entidad referenciable (salvo que se lo referencie en alguna parte del codigo). C estandar OBLIGA a que MAX_COUNT aparesca como simbolo referenciable (otra cosa es lo que pueda optimizar el linker)

C++11 extiende esto todavia mas permitiendonos definir funciones constantes (resolubles en tiempo de compilación) con constexpr, de forma que si escribimos por accidente codigo que el compilador no puede resolver mientras compila, fallará con un error.

No solo eso... las funciones inline (de C++ de siempre) generan más codigo pero la diff de performance puede ser brutal.

Eso puede o no ser cierto, a veces (cuando la funcion hace cosas muy simples, como leer un registro o calcular un valor) puede ser mas constoso crear y destruir el marco de llamada que ejecutar el codigo en si inline (tanto en codigo como en tiempo de ejecución) aunque, para casos normales, lo mas comun es lo que decis vos

Podés elaborar esto (con algún ejemplo concreto)?
 

 

Mi único reparo en usar C++ no es técnico sino "social": una empresa tiene que decidir entre uno y otro sopesándo la mayor o menor facilidad para encontrar recursos idóneos. En mi empresa por ejemplo, tenemos un programador "C++" es en realidad un programador C. Si no ocurriera que yo personamente me puedo ocupar de entrenarlo adecuadamente, tal vez (solo tal vez) usaría C.

Y eso es lo que, normalmente, define el uso de cualquier tecnologia:

* ¿Cuanta gente lo sabe usar?

* ¿Que tan productivos pueden ser para tal problema mis recursos humanos?

* ¿Cuanto le lleva a mi gente adaptarse al conjunto de herramientas?

* ¿Cuanto cuesta en dinero y en horas/hombre esas herramientas?

* ¿Estoy seguro de poder cumplir con los requerimientos con esas herramientas o es un salvavidas de plomo?

Normalmente a los ingenieros tekkies (como yo) no nos gusta hacernos estas preguntas, pero generalmente es lo que define el 90% del problema.

Exacto.

[Fernando Cacciola]

2014-08-21 18:13 GMT-03:00 Matias Vara <matia...@gmail.com>:

Hola, queria solamente realizar un pequeño aporte al hilo. Me da la impresion que para diseño de sistema embebidos el desarrollo se esta moviendo a lenguages más abstractos basados en modelos computacionales (Domain Specific Modeling Language). Luego la fase implementiva  (C, C++, etc) es generada automaticamente. Asi, por un lado se pierde expresividad, porque un DSML es justamente un lenguage hecho a medida, para ganar en verificación o predicibilidad que esta limitada cuando se usa un lenguage de proposito general como C, C++ etc. Por otro lado, también permite hacerse independiente de la implementación.

Y justamente en este sentido, C++ te permite dessarollar un DSL "dentro de C++", gracias a su versatibilidad. Eso da una potencia extraordinaria que en C es impensable.

Aquí hay un ejemplo sacado de Boost.Units:

quantity<electric_potential,complex_type> v = complex_type(12.5,0.0)*volts;
quantity<current,complex_type>            i = complex_type(3.0,4.0)*amperes;
quantity<resistance,complex_type>         z = complex_type(1.5,-2.0)*ohms;

Eso es *directamente* código C++, no algo intermedio que se trabnsforma en C++ (o C o lo que fuera)

[Alvaro Denis]

Hola a todos:
Que tal Sebastián, si estás teniendo problemas con C++ no estás en algo nuevo,
tal vez un lenguaje ideal sería uno que mezcle PYTHON, JAVA y C para sistemas
eso suena un poco difícil pero se escribe fácil GO(http://golang.org/),
este lenguaje viene de la mano de Ken Thompson, Rob Pike y Robert Griesemer.
Con respecto a los comentarios que te dejaron los demás colegas muy de
acuerdo con
la mayoría, incluso el caso en que parecían no coincidir pero cuidado
con tomar tal recomendación
como receta si eres nuevo en C++ y tomas las cosas como receta puedes
tener resultados pésimos,
las personas que te hacian estas recomendaciones se nota que tienen
amplia experiencia
en esta area y saben cuanto tomar tal o cual desición, ya se que
preguntabas por C++
pero en realidad te recomiendo revisar GO y en caso de que necesites
C++ apoyate en Qt
para comenzar que te simplifica muchisimas cosas que son dark en C++
puro. Además
te dejo:
Real-Time C++. Efficient Object-Oriented and Template Microcontroller
Programming.
Christopher Michael Kormanyos. No he tenido tiempo de leerlo pero se ve bien.


Go es un lenguaje muy reciente, 2011 creo y yo lo he aprendido hace un mes, sin
ninguna experiencia en producción así que deberás conciderarlo por tí mismo
en la web, de todos modos aquí señalo algunos de los feactures:
Muy rápido en ejecución(más que python por ejemplo).
Muy rápido en compilación(podría decir que dos proyectos java vs go con java
ya compilado y empaquetado go puedo compilar y ejecutar mientras jre
carga), lei
que la paquetería estándar compila en menos de 5 segundos(no lo
comprobé) en un core 2duo por ejemplo.
Recolector de basura(no predictibilidad temporal, por tanto no tiempo real).
Concurrencia basada en tareas(no estas condenado Bernstein, a menos
que quieras claro).
32 palabras reservadas(C++ tiene el doble o triple, depende el
estandar y la implementación).
Muy portable(la portabilidad es tranparente aunque no hay muchas
implementaciones, ARM por ejemplo SI
tiene y la compilación cruzada es muy sencilla si mal no recuerdo es
solo exportat GOARCH=arm y tener
el toolchain en el path).
Dependes de un sistema operativo tradicional ej:linux, darwin(solo
con intel, ppc no esta implementado creo), ...
.
.
.


Salu2s.



El 21/8/14, Sebastián Zaffarano <se...@zaffarano.com.ar> escribió:

>>> <http://harmful.cat-v.org/software/c++/linus> con la opinión de Linus

>>> Torvalds sobre C++ cuando le preguntaron por qué programó git

>>> <http://git-scm.com/> en C puro.

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


--
Alcanzarás la grandeza... cuando prescindas de la grandeza de los que están
por encima de tí, cuando hagas que los que están por debajo prescindan de
tu propia grandeza, cuando no seas arrogante con el humilde, ni humilde con
el arrogante!!!

[Sebastián Zaffarano]

Muchas gracias Alvaro.

He hecho varias pruebas (proyectos de baja - mediana complejidad para "jugar" mientras leia al respecto) con GO e incluso en mi trabajo utilizo algunas aplicaciones hechas en Go (lo que me da la posibilidad a veces de "meter mano" en el código).  Es un lenguaje que me gusta.  Al igual que python, del que soy fanático.

En si no es que tuve problemas con C++, sino que todo lo que programé para microcontroladores consideré que usando ansi C me alcanzaba (como bien decía Martín, podes programar OO con un lenguaje como C) .  Mi pregunta venía porque en el poco tiempo que estoy en el foro, veo que hay mucha gente con experiencia en C++, más en ámbitos profesionales y no de hobby como es mi caso, y es por eso que quería conocer otros puntos de vista.  La verdad que fue interesante todo lo que se habló, al punto que tengo muchas cosas para leer y probar en base a este hilo.  

Un saludo.

Sebastián

[Mauricio]

Hola Juan Carlos.

Yo aprendi C desde cero a los 19 años leyendo y estudiando de forma autodidacta con el libro Programacion en C/C++ de los autores SIERRA URRECHO ALEJANDRO / ALFONSECA MANUEL de editorial Anaya Multimedia.

Es un libro viejo pero sigue editandose.

http://www.librerias-picasso.com/libro/programacion-en-c-c_44595

http://www.lectorati.com/book/1773247-programacion-en-cc-guias-practicas

Saludos.

Mauricio.

[Carlos Pantelides]

Hola Juan Carlos

Bueno, la cadena se ha hecho muy larga y se han mezclado los temas. Perdón si repito algo ya dicho:

>>también si queres profundizar en C++ podes buscar el libro de STROUSTRUP, que es como el KyR pero de C++

este libro es bastante duro.


Los libros de Stroustrup son dos, el "duro / The C++ Programming Language" y el "no tan duro / Programming: principles and practice using c++"

Carlos Pantelides

@dev4sec

http://seguridad-agile.blogspot.com/