Sessions

REST und JSON sind die defacto Standards um zwischen Anwendungskomponenten Daten über das Netzwerk auszutauschen. Typsicherheit bleibt dabei jedoch oft auf der Strecke und bei Sender und Empfänger werden dieselben Data-Transfer-Objects (DTOs) oft redundant und manuell fehleranfällig typisiert. Der Talk zeigt zunächst auf wie diese Probleme mit Hilfe der Datenbeschreibungssprache OpenAPI inkl. entsprechender Code-Generatoren vermieden werden können. Im letzten Teil wird demonstriert, wie das Problem der Granularität von APIs mit Hilfe von GraphQL gelöst werden kann.

C++20 war groß - sehr groß. Manche sagen sogar, es hatte so viele Neuerungen gebracht, dass es nicht nur Anwender überfordern könnte, sondern auch die Entwickler der Compiler und Standardbibliotheken, sodaß das C++ Komittee in C++23 keine größeren Neuerung bringen sollte. Trotzdem gab es natürlich einen Plan für die Dinge, welche als Ziele für den kommenden Standard vordringlich bearbeitet werden sollten. Und dann kam die Pandemie und notwendigerweise andere Methoden und Vorgehensweisen zur gemeinsamen Arbeit an der Spezifikation von C++23.

Dieses ist wieder ein mehr praxisorientiertes Thema rund um moderne, neue C++ Eigenschaften (C++11 – 20). Bjarne Stroustrup hat in einem seiner Bücher mal geschrieben, dass C++ Entwickler zwar die neuen Eigenschaften von C++11 (und 14, 17, 20) wahrgenommen, aber nicht den grundlegenden Programmierstil geändert haben und neue Paradigmen annehmen. Kann man also an einem so einfachen Beispiel, wie dem Einlesen einer größeren sequentiellen Datei Zeit und Ressourcen sparen, wenn man aktuelles C++ einsetzt?

Auf Veranstaltungen und Schulungen habe ich oft behauptet, dass es möglich ist, mit einer einfachen Wunschliste zu beginnen und daraus ein plattformunabhängiges Programm in C++ zu entwerfen. Damit werden wir unabhängig von Frameworks und Bibliotheken und schützen die Investition Dabei sollte der Beginn sofort möglich sein und in jedes Projekt integrierbar sein. Ich habe aber immer nur den ersten Schritt gezeigt. Das ist jetzt anders. Dieses hatten wir am Anfang mit den beiden Bibliotheken von Embarcadero, der VCL auf der einen Seite und FMX auf der anderen Seite gezeigt. Dann haben wir es verallgemeinert und erweitert und haben Visual C++ genutzt, und die unabhängige Oberflächenbibliothek Qt verwendet.
Damit die Frage auch schon beantworten, natürlich ist es möglich mit einer Schnittstelle, nennen wir sie jetzt einfach mal Wunschliste, zu beginnen und daraus eine unabhängige Lösung für C++ zu schaffen. Dabei muss die Wunschliste möglichst kurz sein, wir sollten uns nicht an dem orientieren was möglich ist, sondern immer an dem was wir wirklich brauchen.
In diesem Vortrag möchte ich ihnen diesen Weg vorstellen und mit Euch diskutieren, wie es noch effizienter geht.

In der Voreinstellung reservieren die Container der C++ Standardbibliothek ihren Speicher mit new und geben ihn mit delete wieder frei. Diese Aufrufe haben keine determinierten Ausführungszeiten und können zu einer Speicherfragmentierung führen.
Das kann in vielen embedded Anwendungen nicht toleriert werden. Die AUTOSAR Regel A18-5-5 verlangt (wie auch entsprechende MISRA-Regeln), dass Speicherverwaltungsfunktionen die folgenden Anforderungen erfüllen müssen:
(a) deterministic behavior resulting with the existence of worst-case execution time,
(b) avoiding memory fragmentation,
(c) avoid running out of memory,
(d) avoiding mismatched allocations or deallocations,
(e) no dependence on non-deterministic calls to kernel.
Deshalb dürfen die Container der C++ Standardbibliothek in solchen Anwendungen nicht verwendet werden.
Seit C++17 stehen die STL Container aber mit Allokatoren aus dem namespace std::pmr (polymorphic memory resources) zur Verfügung. Diese verwenden kein new und delete. Die Container mit diesen neuen Allokatoren können oft so verwendet werden, dass die Anforderungen AUTOSAR Regel A18-5-5 erfüllt werden. Damit kann man das erste Mal in der Geschichte von C++ die Vorteile der STL Container in einem großen Teil der embedded Welt nutzen.

Docker & Co sind nicht nur Ops, sondern auch Dev. Eine kurze Geschichte wie Docker die Entwicklung mit C++ bereichert.

Beim Entwickeln einer C/C++ Software Bibliothek sollte bereits zu Anfang ein Augenmerk auf die einfache Integration der Bibliothek gelegt werden.
Dies gilt insbesondere für Bibliotheken, welche später von externen Nutzern in deren Anwendungen integriert werden sollen.
Da in vielen Projekten bereits CMake als Buildsystem verwendet wird, liegt es nahe, auch CMake für die Beschreibung der Compiler und Linker Optionen, sowie abhängiger Bibliotheken und deren Header zu verwenden.
Bei korrekter Beschreibung reichen dann folgende zwei Zeilen zur
Integration:
find_package(foo REQUIRED)
target_link_libraries(myapp PRIVATE foo::foo)
Der Vortrag führt anschaulich durch den Prozess des Paketierens unter Berücksichtigung folgender Ziele:
(a) einfache Integration der Bibliothek in eine Anwendung
(b) Erkennen fehlender Abhängigkeiten vor dem Kompilieren
(c) kein Spamming: Compiler und Linker Optionen nur dort wo benötigt hinzufügen
(d) flexible Paketierung: Einfache Integration in OS Distributions
(e) Unterstützung nicht CMake basierter Buildsysteme (z.B. mittels PKG-Config)
Hierbei geht der Vortrag insbesondere auf die Unterschiede zwischen Import und Export Targets, Find_Package und PackageConfig Skripten sowie Private / Interface / Publik Relationen ein.

Mikrocontroller ohne Betriebssystem sind ein zentraler Bestandteil vieler eingebetteter Systeme. Weil diese Systeme direkt mit der Außenwelt interagieren können, sind sie oft hohen Leistungs- und Sicherheitsanforderungen unterworfen. Diese decken sich mit einigen Werten und Konzepten des Rust Projektes: hohe Performance bei niedrigem Speicher- und Energiebedarf, definiertes Verhalten und sichere Nebenläufigkeit, sowie Compiler und Tooling, welche uns Entwicklern zur Seite stehen.
Natürlich gibt es auch Herausforderungen für Bare Metal Rust - die großzügige Nutzung (auch transitiver) Abhängigkeiten scheint zunächst ungewöhnlich, man begegnet mehrzeiligen Typsignaturen, und für Asynchronizität (Interrupts, DMA, oder Multitasking) wird mit verschiedenen Ansätzen experimentiert.
Wir werden in dieser Session von den Grundlagen der Rust Bare Metal Programmierung ausgehen, um dann Bibliotheken kennenzulernen, welche die Entwicklung portabler Treiber und deren Tests ermöglichen. Dabei werden uns einige Design Patterns, Architekturen, und Tools über den Weg laufen. Zu guter Letzt halten wir einen Ausblick auf Asynchronizität in Embedded Rust.

In der Rust Community wurde lange diskutiert und experimentiert, um ein solides Fundament für asynchrone Programmierung zu finden. Seit Ende 2019 ist async/.await endlich in "stable" verfügbar, und das Ökosystem evolviert rapide.
Doch wie passen Event Loops und asynchrone Laufzeitumgebungen in die Konzepte der Programmiersprache Rust, welche auf Zero-Cost Abstractions, (Thread-)Safety by Design, und höchstmögliche Leistung in allen Bereichen setzt? Und, wie ergonomisch und praktikabel ist asynchrones Rust?
In dieser Session werden wir einige Grundlagen erkunden und dann mithilfe beliebter Bibliotheken in die Praxis einsteigen. Dabei werden uns asynchrone Design Patterns, strukturierte Nebenläufigkeit, Tooling, sowie ein paar Gotcha's und Antipatterns begegnen.

Rust ist seit einigen Jahren in aller Munde. In dieser Session erklärt Rainer Stropek, warum er sich in Rust „verliebt" hat. Wer neugierig auf Rust ist, aber noch nicht so recht weiß, ob die Plattform den Lernaufwand wert ist, der ist in dieser Session genau richtig.

Intel und die Khronos Group haben mit Data Parallel C++ (DPC++) und SYCL eine neue Möglichkeit geschaffen Anwendungen für verschiedene Zielarchitekturen mit einer einheitlichen Codebasis zu entwickeln. Wir geben einen Einblick zu den zur Verfügung stehenden Sprach-Konstrukte, Erweiterungen und die zur Zeit unterstützten Zielarchitekturen. Demonstrationen mit einer Auswahl an DPC++- tauglichen Entwicklungswerkzeugen runden den Vortrag ab.

In dieser Session stellt Daniel fortgeschrittene Wege vor, wie Sie Ihre UML- oder SYSML-Modelle zusammen mit Ihrem Code in Git verwalten und beides in Ihre kontinuierlichen Integrationslösungen (CI) integrieren können.
Die Verwaltung der Modelle zusammen mit dem Code in denselben Zweigen - unter Verwendung von Prozessen aus dem Software-Engineering - ermöglicht es, die komplexen cyber-physikalischen Systeme von heute mit Stil zu entwickeln, ohne dabei die Anforderungen aus sicherheitskritischen Normen zu opfern

In seinem deutschsprachigem Vortrag stellt Frank Haferkorn Details zur Compound-Gruppe "LOOP" für C/C++ vor. Nach einer Erläuterung der Syntax werden die Implementierung sowie Vor- und Nachteile der neuen Kontrollflussbefehle ausführlich erklärt - inklusive einer Vergleich Performance.
Die ursprünglichen C Kontrollfluss-Befehle haben sich seit Ende der 1970er Jahre wenig bis gar nicht verändert, Sie heißen „Compound(s)" und sind in die wohlbekannten if-else, while, do-while, for sowie switch und wurden in C++ erweitert um try{}catch(){} block sowie mit C++17 um if(;) und switch(;).
Ist es ein physikalisches Gesetz, dass keine weiteren Compounds hinzukommen dürfen?
Besprochen wird eine für C11, C++11 und C++20 angepasste „Header-Only" Lösung von:
loop(<N>){},
typed_loop(<type>, <N>){},
named_loop(<type>, <name>, <N>){}
named_loop_up(<type>, <name>, <N>){}
named_loop_down(<type>, <name>, <N>){}
Frank Haferkorn präsentiert sowohl eine C, eine C++11 als auch eine um Post-Expressions erweiterte Implementierung für C++20.
Die Vorteile sind Iterationen mit reduziertem Freiheitsgrad, verbesserter Lesbarkeit von C/C ++ und erlauben einfachere / performantere Notation von Algorithmen.
Ein Nebeneffekt ist eine Verbesserung der Teachability von C/C++ insbesondere für die Raspberry PI Generation.
(Zukünftige) Compiler können aufgrund des reduzierten Freiheitsgrads kürzeren Maschinencode Code mit zusätzlich reduzierter Zahl von „Cache-Misses" und damit eine Performance Gewinn erzielen.
Die Performance ist immer mindestens dem eines regulären for(;;){} Compound Befehls.
Eine Performance Analyse für verschiedenen CPU/DSP Plattformen und einer eine abschließende Diskussion darf nicht fehlen.