Nuevo C++ (C++11) y electrónica integrada

Me pregunto si el nuevo C ++ (que se llama C ++ 11) funciona bien con la electrónica integrada y la programación. ¿Las nuevas funciones se ajustan bien si se trabaja con uC? ¿Como los valores R, etc.? ¿O debería restringirse con el C++ tradicional y de estilo antiguo?

Meh. Todo se reduce al código ensamblador al final.
Me gustaba más cuando era C++0x ..
Los valores R en C++ 11 son una BS total. Los chicos de C estaban haciendo eso incluso antes de la existencia de C++.
@IgnacioVazquez-Abrams - Eso es completamente irrelevante.
¿C++ de estilo antiguo ? ¿C++ es viejo ahora? ¡Me siento muy viejo entonces, solo trabajando con C!
@AngryEE LOL No quiero decir que C ++ sea viejo, aunque, si lo es, creo que es el MEJOR. Pero me refiero a las características anteriores a C++11.
Por mi parte me gusta programar micros en lenguaje C tradicional
El mejor C ++ (lo que sea) para usar con microcontroladores sigue siendo C.

Respuestas (1)

No es C ++ 11 o C ++ de estilo antiguo, al igual que no es solo C o C ++ que usa todas sus funciones. Me encanta usar C++, pero odio algunos aspectos específicos. (Esto no es específico de C++, aunque hay lenguajes que odio sin excepción.) Tome las partes buenas (después de comprobar que están implementadas decentemente), deje el resto para otros o para más adelante.

Todavía no he usado las especificaciones de C++ 11 (mis lecciones para este trimestre son C++ en NDS usando devkitPro, que tiene un gcc antiguo). Pero una característica simple que espero con ansias es la variable autoescrita. Suponga que desea construir diferentes tipos de objetos (todas las subclases de una clase base), dependiendo de los tipos de parámetros del 'constructor'. No puede sobrecargar constructores de diferentes clases, pero puede sobrecargar varias funciones que devuelven diferentes tipos de clases. Pero para almacenar los resultados, debe recordar el tipo exacto que devuelven (lo que estropea el patrón de fábrica en mi opinión) o hacer que todos devuelvan un puntero al tipo de clase base (lo que lleva la gestión del montón a su aplicación, que trato de evitar) . Con la función automática puedes hacer

a_very_long_and_difficult_to_remember_class f( int x );
an_equaly_difficult_to_remember_class f( char *p );

auto x = f( 12 );
auto y = f( "hello" );

Para mí, esto significa que un patrón atractivo de repente es muy fácil de usar.

No veo cómo esto aborda la pregunta del OP, que trata sobre la idoneidad de C++ 11 para sistemas integrados.
En el primer párrafo, argumento que "ya sea para C++ 11 o no" no es una pregunta, al igual que "para C ++ o para C". Cuando pueda usar una cadena de herramientas habilitada para C ++ 11, verifique qué características son útiles para usted. La función que muestro hace que usar el patrón de fábrica sea fácil y al mismo tiempo 'prohibe' el uso de memoria dinámica (que es o debería ser una preocupación en una aplicación con recursos limitados). PD: Creo que el comentario de IVA es irrelevante.
Eso no estaba del todo claro en la publicación. El comentario de IVA es malo porque sugiere que cualquier herramienta que genere ensamblador es equivalente. Uno podría usar felizmente las características de C ++ que son más inapropiadas para una MCU, mientras se dice a sí mismo "Al final, todo es ensamblador". He visto esto pasar.
En ese caso, es al menos un poco descuidado, porque dice "código ensamblador", lo que para mí implica codificar en lenguaje ensamblador. Para otros significados debería decir algo como 'instrucciones de máquina', lo cual es totalmente correcto pero igualmente inútil.