The USE of C++ | Videocast 

In Python habe ich früher dann mit asyncio gearbeitet um bestimmte IO Tasks zu synchronisieren, wird allerdings bei komplexen Programmen schwierig den Überblick zu bewahren.

Was meinst du genau mit "wenn man mal astrakter über die Programmierung bzw. die Sprache spricht"

@@alexanderseizinger7243 Ich meine damit, dass man nicht z.B. "Das ist ein if statement und das macht das und das." sagt sondern mal über code schnipsel redet, wer mit wie viel wissen das wie machen würde und welche optionen man hat. Grade so Sachen die allgemein zur Programmiersprache (z.b. standards wie c++ 17 etc.) werden meiner Meinung nach nicht häufig genug betrachtet.

@@Timm2003 The Morpheus liest hier ja mit, vielleicht lädt er mich mal wieder ein ;)

@@alexanderseizinger7243 Schau ich mir dann auf jeden Fall wieder an. 👍

Grund dafür sind Compiler- und Librarysupport (Stichwort Toolchain). C ist eben nochmal etwas älter und verändert sich langsamer als C++, weswegen oft die Programmierer dafür opten

Bin kein Compilerbau-Experte aber ein Grund liegt sicherlich darin, dass es viel einfacher ist/weniger Aufwand kostet einen C-Compiler zu entwickeln (da C verglichen zu C++ einen viel geringeren Sprachumfang hat)

@@alexanderseizinger7243 Ja, das ist korrekt. C++ ist deutlich schwerer zu parsen, speziell was Templates angeht. Du kannst mal nach "the most vexing parse c++" suchen, das ist ein Talk der cppcon der darüber redet.

Arduino Libraries sind imho alle C++. Worin die Arduino Sketches geschrieben werden, weiss ich nicht.Aber da das meiste in was C geschrieben ist, auch von einem C++ Compiler übersetzt werden kann, denke ich mal ebenfalls C++. Die Support Libraries für die meisten Mikrocontroller sind in C, da man damit sowohl die reinen C User als auch die C++ Crew erreicht.

Why not both? 🤷

es soll Menschen geben, die Rust Syntax besser finden 🤷‍♂

Da es nicht Thema des Videos war wollte da nicht zu sehr ins Detail gehen. Ein Level präziser haben die Einschränkungen mit Folgendem zu tun - Dynamische Speicherverwaltung ist nur ein Aspekt und wie angedeutet gibt es dafür durchaus (teilweise) Lösungen. - Der Umgang mit Exception-Handling (inwiefern das ein Problem dastellt hängt stark vom eingesetzten Safety Konzept ab) - Die (fehlende) formale Qualifizierung / Zertifizierung der Container/Algorithmen Nicht davon ist pauschal unlösbar, aus meiner Erfahrung wird aber häufig der Weg gewählt, auf STL oder wesentliche Teile davon zu verzichten.

@@alexanderseizinger7243 Danke schön für deine Antwort. Mir ging es nur um den Punkt der dynamischen Speicherverwaltung im Embedded. Dass der Umgang mit Exceptions und die fehlende Qualifizierung der Container bei Safety ein Problem ist, stimme ich dir zu. Ich wollte nur auf den Punkt aufmerksam machen, dass die generelle Aussage "STL Container und STL Algorithmen können nicht im Embedded Umfeld genutzt werden" einfach nicht mehr stimmt. Das hast du so nicht gesagt, aber es lässt sich leicht so verstehen und an diesem Punkt habe ich schon oft die alten C Entwickler kommen sehen, die dann der Meinung sind, dass man damn C++ für Embedded gar nicht braucht, sondern lieber gleich bei C bleibt. Nochmal ich sage nicht, dass du das gesagt hast und ich möchte dir auch nicht unterstellen, dass du so denkst. Ich wollte nur für genau solche Diskussionen mit C Entwicklern das Wissen weiter verbreiten, dass die STL dieses Problem schon behoben hat.

Unterschiedliche Lösungsmöglichkeiten können als etwas positives betrachtet werden weil sie eben nicht alle gleich sind. Die Flexibilität bedeutet häufig dass man es im Detail anders machen kann und dadurch ist man generell mächtiger was die möglichen Lösungen angeht. Diese Flexibilität geht auf Kosten der Wartbarkeit und einer höheren Komplexität bzw. Fehleranfälligkeit. Ich finde die Analogie mit einem Felskletterer amüsant: Rust ist anspruchvolles klettern an einer Feldwand mit einer Absicherung für den Fall der Fälle. C++ ist das selbe ohne diese Absicherung (wobei man sie optional aufrüsten kann). Man kann bei beiden fatale Fehler machen und abstürzen aber bei Rust ist es deutlich schwieriger abzustürzen. Und Python ist ein mechanischer Aufzug das entlang der Felswand verläuft xD Kann auch abstürzen aber ist nochmal viel unwahrscheinlicher.

Warum kein Rust oder Zig? Zig ist von der Spezifikation noch gar nicht finalisiert. Diese Sprache ist für den professionellen Einsatz noch nicht geeignet. Rust: Es gibt kaum Entwickler, die Rust wirklich können. Rust ist nicht wirklich leicht zu erlernen. Mitarbeiter in diese Richtung zu schulen, ist entsprechend aufwendig. Da ist dann die Frage, ob sich das für Unternehmen wirklich lohnt. Zudem sind die meisten SDKs für Embedded Controller in C oder C++ geschrieben.

@@elpenny81 Zig klar, verstehe ich, fände ich nur rein aus konzeptioneller sich interessant also was müsste es noch können/wie müsste es noch sein. Bei Rust finde ich den Punkt schon da aber nicht so stark. Ich habe im bereich embedded software gearbeitet und dort auf Grund der schlechten Software qualität die die meist frisch von der Hochschule kommenden Entwickler geleistet haben alles auf Rust aufgebaut. Das lernen von Rust hat natürlich eine Zeit gedauert, das hätte es aber auch C++ ordentlich zu lernen. Kann natürlich je nach Hoschschule oder Vorqualifikation anders sein, also natürlich nicht generell anwendbar