Neues C++ (C++11) und eingebettete Elektronik

Ich frage mich, ob das neue C++ (das C++11 hieß) gut mit der eingebetteten Elektronik und deren Programmierung funktioniert. Passen die neuen Features gut zur Arbeit mit uC? Wie R-Werte und so weiter? Oder sollte mit dem traditionellen und alten C++ eingeschränkt werden?

Meh. Am Ende läuft alles auf Assemblercode hinaus.
Ich mochte es mehr, als es C++0x war .
R-Werte in C++11 sind insgesamt BS. C-Leute haben das schon vor der Existenz von C++ gemacht.
@IgnacioVazquez-Abrams - Das ist völlig irrelevant.
C++ im alten Stil ? C++ ist jetzt alt? Da fühle ich mich sehr alt, arbeite nur noch mit C!
@AngryEE LOL Ich meine nicht, dass C ++ alt ist, obwohl ich denke, dass es das BESTE ist, wenn es so ist. Aber ich meine die Features vor C++11.
Ich für meinen Teil programmiere Mikros gerne in der traditionellen C-Sprache
Das beste C++ (was auch immer) für Mikrocontroller ist immer noch C.

Antworten (1)

Es ist nicht C++11 oder C++ im alten Stil, genauso wie es nicht nur C oder C++ ist, das alle seine Funktionen verwendet. Ich liebe es, C++ zu verwenden, aber ich hasse bestimmte Aspekte davon. (Dies ist nicht C++-spezifisch, obwohl es Sprachen gibt, die ich ausnahmslos hasse.) Nehmen Sie die guten Teile (nachdem Sie überprüft haben, ob sie anständig implementiert sind), überlassen Sie den Rest anderen oder für später.

Ich habe noch keine C++11-Spezifika verwendet (meine Lektionen für dieses Quartal sind C++ auf NDS mit devkitPro, das einen alten gcc hat). Aber eine einfache Funktion, auf die ich mich freue, ist die automatisch typisierte Variable. Angenommen, Sie möchten verschiedene Arten von Objekten (alle Unterklassen einer Basisklasse) erstellen, abhängig von den Typen der 'Konstruktor'-Parameter. Sie können Konstruktoren verschiedener Klassen nicht überladen, aber Sie können verschiedene Funktionen überladen, die unterschiedliche Arten von Klassen zurückgeben. Aber um die Ergebnisse zu speichern, müssen Sie sich entweder den genauen Typ merken, den sie zurückgeben (was meiner Meinung nach das Fabrikmuster verdirbt), oder sie alle einen Zeiger auf den Basisklassentyp zurückgeben lassen (was die Heap-Verwaltung in Ihre Anwendung zieht, was ich zu vermeiden versuche). . Mit der Auto-Funktion können Sie tun

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" );

Für mich bedeutet das, dass ein attraktives Muster plötzlich sehr einfach zu handhaben ist.

Ich sehe nicht, wie dies die Frage des OP beantwortet, bei der es um die Eignung von C ++ 11 für eingebettete Systeme geht.
Im ersten Absatz argumentiere ich, dass „ob zu C++11 oder nicht“ eine Nichtfrage ist, genau wie „zu C++ oder zu C“. Wenn Sie eine C++11-fähige Toolchain verwenden können, prüfen Sie, welche Funktionen für Sie hilfreich sind. Die Funktion, die ich zeige, macht die Verwendung des Factory-Musters einfach, während die dynamische Speichernutzung immer noch "verboten" wird (was in einer ressourcenbeschränkten Anwendung ein Problem ist oder sein sollte). PS Ich bin der Meinung, dass der Kommentar von IVA irrelevant ist.
Das ging aus dem Beitrag überhaupt nicht hervor. Der Kommentar von IVA ist schlecht, weil er darauf hindeutet, dass jedes Tool, das Assembler generiert, gleichwertig ist. Man könnte glücklicherweise die Features von C++ nutzen, die für eine MCU am unpassendsten sind, während man sich sagt: „Am Ende ist alles Assembler“. Ich habe dies geschehen sehen.
In diesem Fall ist er zumindest ein bisschen schlampig, weil er "Assembler-Code" sagt, was für mich das Codieren in Assembler-Sprache impliziert. Für andere Bedeutungen sollte er so etwas wie „Maschinenanweisungen“ sagen, was völlig richtig, aber ebenso sinnlos ist.