Modules sind wahrscheinlich die einflussreichste und umwälzendste Neuerung in C++. Aus Anwendersicht sind Moduls konzeptionell einfach und die Idee ist leicht zu verstehen. Und da das C++20-Ökosystem heranreift, ist die Verwendung von Modules und ihre Übernahme in die alltägliche Programmierung sowohl machbar als auch vorteilhaft. Aber was sind die geheime Zutaten der Modules, die sie so schmackhaft machen? Es gibt drei Teile im C++-Sprachpuzzle, die seit den Anfängen der Sprache existieren, aber im typischen Gebrauch von "klassischem" C++ meist irrelevant sind und von denen kaum ein Programmierer viel wissen muss. Keine Angst - daran hat sich nichts geändert, kein alter Hase muss neue Tricks lernen, um die Macht der Modules zu nutzen. Aber wenn Sie sich dafür interessieren, wie drei kleine (Schlüssel-)Wörter diese Macht entfesseln können, möchten Sie vielleicht verstehen, was Visibility von Namen, Reachability von Deklarationen und deren semantische Properties sowie Linkage in der Welt der Modules eigentlich bedeuten.
Der Vortrag wird
- einen kurzen Überblick darüber geben, was Modules sind
- das Konzept der Visibility erläutern
- Deklarationen, semantische Properties und den Unterschied zwischen Visibility und Reachability erläutern
- einen Blick auf die sogenannte Linkage und Linker-Symbole werfen

Die IT- Landschaft hat sich im Laufe der Jahre zu einer energieintensiven Industrie entwickelt, die einen höheren CO2- Fußabdruck hat, als die weltweite Luftfahrtindustrie. Dabei werden immer mehr Funktionen in Serverfarmen verlegt und eine Welt ohne Internet ist nicht mehr denkbar. Deshalb wird der Energieverbrauch in den nächsten Jahren stark ansteigen. Während wir über innerdeutsche Businessflüge und Autofahrverbote diskutieren, bleibt die Verantwortung der Softwarefirmen aber weitestgehend unbekannt. Welche Verantwortung haben wir als Softwareentwickler und welche Lösungsmöglichkeiten gibt es. Welche Faktoren spielen eine Rolle.

Mit C++20 steht wieder ein richtiger großer C++-Standard vor der Tür. Concepts, die Ranges Bibliothek, Coroutinen und Module werde die Art und Weise, wie wir modernes C++ programmieren, grundlegend neu definieren. Concepts sind eine Erweiterung von Templates von C++, mit denen sich semantische Kategorien für die Menge der zulässigen Datentypen definieren lassen. Dank Concepts wird das Anwenden und Definieren von Templates deutlich einfacher und ausdrucksreicher. Die Ranges Bibliothek erlaubt es, die Algorithmen der Standard Template Library direkt auf den Container anzuwenden, diese mit dem aus der Unix-Shell bekannten Pipe-Operator zu verknüpfen und diese auf unendlichen Datenströmen zu definieren. Mit Couroutinen unterstützt C++20 die asynchrone Programmierung. Damit werden sich in C++20 kooperatives Multitasking, unendliche Datenströme, Event-Schleifen oder auch Pipelines elegant umsetzen lassen. Module stellen eine Alternative zu Header-Dateien dar und versprechen viele Verbesserung. Die Trennung von Header- und Sourcecodedateien aufzulösen, Präprozessor-Anweisungen zu eliminieren, bessere Kompilierungszeiten zu erzielen und einfacher Pakete zu schnüren.

C++20 führt eine neue Klasse zum Starten von Threads ein: std::jthread. Diese kann deutlich einfacher verwendet werden und bietet neue Möglichkeiten wie das kooperative Beenden von gestarteten Threads. Dieser Vortrag erklärt warum es dazu kam, welche neuen Optionen es gibt und warum std::thread nicht mehr verwendet werden sollte.

C++ wird für sicherheitskritische und moderne Embedded Systeme genutzt. Weil C++ zum einen viele low-level Merkmale von C geerbt hat, erlaubt es leider problematischen Code zu schreiben, der fehlerträchtig oder gar fehlerhaft ist und trotzdem kompiliert. Programmierrichtlinien schränken deshalb die Nutzung von C++ auf einen sichereren Sprachkern ein, wie zum beispiel solche für den Einsatz in der Automobilindustrie wie MISRA-C++202x. Dieser Vortrag zeigt wie für sicherheitskritische Systeme solche Einschränkungen gefordert und geprüft werden und was von den neuen MISRA-C++:202x Safety Richtlinien zu erwarten ist. Auch ein paar generelle C++ Designrichtlinen werden kurz angerissen, wie die Nutzung von "Strong Typing" und von Ganzzahltypen mit bewusst eingeschränktem Funktionsumfang und ohne "Undefined Behavior".

In letzter Zeit haben partiell-geformte (partially-formed) Objekte als natürlicher Zustand von moved-from Objekten an Zugkraft gewonnen. Alexander Stepanov definiert sie in seinem wegweisenden Buch Elements of Programming (EoP) als einen Zustand, in dem die einzig gültigen Operationen Zuweisung und Zerstörung sind. Dieser Status war und ist für Hochleistungscode und die C++-Garantie "don't pay for what you don't use" von wesentlicher Bedeutung.
Nach einer kurzen Einführung werden wir uns ansehen, wo in der C/C++-Sprache solche Zustände auftraten, noch bevor es ein "C++" oder den Namen "partiell geformt" gab und sicherlich bevor die Diskussion über den moved-from Zustand begann. Wir zeigen damit, dass egal, wie Sie über das partiell-geformte Zustandskonzept denken, es als platonisches Ideal in der Welt der Computerprogrammierung vorhanden ist. Wir werden nichts weniger versuchen, als die EoP-Behandlung weiter in das moderne C++ zu übertragen. Wir werden feststellen, dass die Move-Semantik, wie sie derzeit im Standard definiert ist, zu stark ist, da sie gegen "don't pay for what you don't use" verstößt, und einen Überblick über schwächere Alternativen geben, die ebenso leicht zu erlernen und zu begründen sind, aber natürlichste und effizienteste Implementierungen von Typen ermöglichen, die sie verwenden. Ein Paradebeispiel wird flat_map sein.
Wir werden auch zeigen, wie Entwickler, die sich mit dem partiell-geformten Zustand unwohl fühlen, ihn ohne oder mit nur geringen Kosten (weder hinsichtlich der Lesbarkeit des Codes noch des Laufzeitverhaltens) vermeiden können, und anhand dieser Beispiele ein neues (altes) Paradigma für API-Design vorschlagen: sicher und unsichere Funktionen (im Sinne von Sean Parent).

Ups, unsere Anwendung ist abgestürzt und wir können es nicht nachstellen. Wieso läuft unsere Anwendung out-of-memory? Kennen Sie diese Aussagen und fragen sich zudem, wie Sie der Ursache auf den Grund gehen können? Vielleicht, weil es nur mit der Releaseversion Ihrer Anwendung passiert. Dann sind Sie hier genau richtig. Diese Session betrachtet auf der einen Seite mögliche Ursachen von Fehlern im Programmcode und beleuchtet auf der anderen Seite, welche Möglichkeiten Sie haben, gerade in Releaseversionen die Ursache von Fehlern zu finden. Und ganz nebenbei lernen Sie etwas über den Aufbau Ihrer Anwendung.

Wir werden täglich mit computergenerierten Bildern bombardiert – sei es aufgrund von Marketing, im Fernsehen, in Hollywood-Filmen, in Simulationsprogrammen oder in Computerspielen. Doch wie werden komplexe Geometrien und Materialien dargestellt? Wie sieht eine Rendering-Pipeline aus? Welche Mathematik steckt dahinter? Der Vortrag „An Introduction to Computer Graphics" beantwortet diese (und weitere) Fragen und führt vor, wie mittels C++ und OpenGL Geometrien grafisch zum Leben erweckt werden.

C++ hat seine Stärken in der systemnahen Programmierung und in performancekritischen Anwendungsteilen. Auch für grafische Benutzeroberflächen gibt es ausgereifte Bibliotheken wie etwa Qt, die sich vielfach in der Praxis bewährt haben. Auf der anderen Seite gibt es in den letzten Jahren große und sehr interessante Fortschritte bei Tools und Bibliotheken der webbasierten UI-Entwicklung. In einer ca. 10 Jahre alten Codebasis, bis dahin komplett in C++ und Qt Widgets geschrieben, fällten wir daher die Entscheidung, in der UI-Entwicklung zukünftig auf TypeScript und React zu setzen und somit Qt Widgets schrittweise zu ersetzen. Dieser Vortrag ist ein Erfahrungsbericht dieser Transition: Warum haben wir uns für dieses Vorgehen entschieden, statt z.B. auf Qt QML zu setzen? Welche Stärken der webbasierten UI-Entwicklung waren ausschlaggebend? Wie funktioniert die Kommunikation zwischen dem TypeScript-Code der UI und dem C++-Code der Anwendungslogik? Welche Auswirkungen hat das Vorgehen auf die Developer Experience und das Packaging bzw. Deployment der Anwendung? Welche Möglichkeiten gibt es, die Qt-basierte UI schrittweise, statt alles auf einmal, zu ersetzen? Welche technischen Stolperfallen galt es zu überwinden und welche Fehler haben wir dabei gemacht? In dem Vortrag beantworte ich all diese Fragen und möchte retrospektiv noch einmal kritisch hinterfragen, ob sich die Entscheidung als die richtige erwiesen hat.

Nachdem ARM Chips wie beispielsweise der Raspberry Pi im privaten Umfeld immer beliebter wurden, ist dieser Trend nun auch im Industrie Kontext zu beobachten. Somit wird auch das Thema Softwarenentwicklung für diese Plattformen immer wichtiger. Da die SOCs jedoch meist nur sehr wenig RAM und CPU Ressourcen bieten, ist es oft nicht möglich / sinnvoll, direkt auf den Boards Software zu kompilieren. Stattdessen verwendet man besser Cross-Compiler, um auf einem leistungsstarken x86 System das Binary für den ARM Chip zu erzeugen. Im Vortrag werden hierzu bewährte Toolchains und Techniken vorgestellt, um die Entwicklung für Fremdarchitekturen effizient zu gestalten. Dies umfasst insbesondere die GCC Crosscompiler, CMake Toolchains, Emulation mittels QEMU, Debian multiarch Support und Docker multiarch containers. Abschließend werden die gezeigten Ansätze an einem Beispiel demonstriert. Hier wird gezeigt, dass "ARM nicht gleich ARM" ist, und insbesondere die korrekte Verwendung von Compiler-Flags bei rechenintensiven Anwendungen (Bilderkennung / KI) einen großen Performance Gewinn bringt.

Seit wenigen Monaten ist der C++20 Standard offiziell. Es ist wahrscheinlich die größte Änderung der Sprache. In diesem Vortrag schauen wir auf Änderungen im Bereich Templates, genauer die Einführung von Concepts. Wir schauen uns an wie wir Konzepte definieren und wie sie sich aus Requirements zusammensetzen. Mit diesem Wissen entwerfen wir ein eigenes Konzept inklusive Tests. Wir schauen weiter auf die Erweiterungen von NTTPs und CTAD. Teilnehmer sind nach dem Vortrag mit den Grundlagen von Concepts vertraut und können Concepts einsetzen. Am Ende des Vortrags kennen die Teilnehmenden die neuesten Änderungen im Bereich C++20-Templates und Anwendungsmöglichkeiten.

In seinem deutschsprachigem Vortrag stellt Frank Haferkorn die Compound-Gruppe "LOOP" als eine C/C ++ Core-Language Extension vor. Die ursprünglichen C Kontrollfluss-Befehle haben sich mindestens seit 1978(!), seit der Veröffentlichung von Kernighan&Ritchies „K&R C" wenig bis gar nicht verändert, Sie heißen „Compound(s)" und sind in die wohlbekannten if-else, while, do-while, for und switch. Nur ein Compound in Form des try/catch Blocks hat sich in C++ hinzugesellt. Seit C++ 17 gibt es ein kleinere weitere Entwicklungen. Ist es ein physikalisches Gesetz, dass niemals weiteren Compounds hinzukommen dürfen?
Die hier vorgestellten neuen Compounds
• loop(){},
• typed_loop(){},
• named_loop_up(){} und
• named_loop_down(){}
ermöglichen eine simple Codierung einfacher Iterationen.
Auch wenn dies kein neues Major-Feature werden wird, habe diese Vorteile. Sie reduzieren die Komplexität, verbessern die Lesbarkeit von C/C ++ und werden zu anderen/einfacheren Notationen (auch bestehender) Algorithmen führen. Compiler können aufgrund reduzierter Komplexität performanteren Code erzeugen.
Eine Verbesserung der Teachability von C/C++ ist zu erwarten und damit sinkt die Einstiegsschwelle in C für zukünftige C/C++ Entwickler aus der heutigen Raspberry Generation.
Frank Haferkorn zeigt die Syntax, erklärt die grundlegende Verwendung erläutert die Anwendung Anhand von Beispielen, diskutiert die Vor- und Nachteile und präsentiert zuerst eine reine C-Implementierung alleinig basierend auf dem C-Preprocessor mittels Variadischen Makros. Für eine elaboriertere C++ Implementierung sind noch einige weitere C++ Kniffe nötig…
Auch bekannte Probleme mit der derzeitigen Implementierung dürfen nicht fehlen.
Die LOOP Compounds sind implementiert als einzelne header-only include Datei.

n 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. In vielen embedded Anwendungen kann das nicht toleriert werden. Die AUTOSAR Regel A18-5-5 verlangt, 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. Mit C++17 kann man STL Container aber doch auch in vielen embedded Anwendungen verwenden. Die neuen Allokatoren aus dem namespace std::pmr (polymorphic memory resources) können so verwendet werden, dass die Anforderungen (a), (b) und (e) erfüllt werden. Da (d) für die STL erfüllt ist, können die Container der C++ Standardbibliothek mit diesen pmr Allokatoren verwendet werden, wenn man (c) zusichern kann. Das ist für viele (aber nicht alle) embedded Anwendungen möglich. 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.

C++11-Lambdas brachten uns Lambdas. Sie eröffnen viele neue Möglichkeiten. Häufig gestellte Fragen sind:
- Wie werden sie umgesetzt?
- Wie kann es meine tägliche Programmierung beeinflussen?
- Generieren sie viel Code?
- Wo kann ich sie benutzen?
In diesem Vortrag werde ich diese Fragen beantworten. Mit der Unterstützung von C++ Insights werden wir einen Blick hinter die Kulissen werfen, um Fragen zur Implementierung von Lambdas zu beantworten. Wir werden auch sehen, wie sich der vom Compiler generierte Code ändert, wenn wir das Lambda selbst ändern. Dies ist häufig für die Entwicklung in eingeschränkten Anwendungen wie eingebetteten Systemen interessant.
Als nächstes zeige ich Ihnen Anwendungsbereiche von Lambdas, um zu zeigen, wo sie hilfreich sein können. Zum Beispiel, wie Lambdas Ihnen helfen können, weniger und aussagekräftigeren Code zu schreiben.
Nach dem Vortrag haben Sie ein solides Verständnis von Lambdas in C++. Zusammen mit einigen Ideen, wann und wo sie verwendet werden sollen.

Futures, Promises, Observables, Subscriptions? Das Reaktive-Programmierparadigma ist seit einigen Jahren in vielen Programmiersprachen verfügbar und ist seit 2018 auch in C++ angekommen. Dieser Vortrag bietet einen aus der Praxis motivierten Einstieg in dieses Thema. Wir starten ganz vorne bei den Threads und hangeln uns über Futures und Promises zu den Observables. In diesem Zuge betrachten wir verschiedene Bibliotheken zu diesem Thema und deren Features und Limitierungen. Im letzten Teil betrachten wir einige Beispiel-Lösungen bei denen sich der Einsatz des reaktiven Paradigmas lohnt.

Typen aus den Anwendungsdomäne ermöglichen es besseren und sauberen Quellcode zu schreiben. In dem Vortrag tauchen analysieren wir verschiedene Strategien Strong Types in C++20 umzusetzen. Mit dem Überblick sollte es jedem Zuhörer möglich sein, Strong Types best möglich für seinen Anwendungsfall zu nutzen.

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.

Bei der Entwicklung einer Desktop-App geht es heutzutage nicht nur um Schnelligkeit sondern auch um Optik. Eine Anwendung muss intuitiv sein, modern aussehen und gleichzeitig schnell reagieren. Durch die Kombination von WinUI 3 und C++ wird genau das erreicht – native Performance mit C++ und ein modernes Userinterface durch WinUI 3 mithilfe des Fluent Design. In einer Live-Demo wird der Aufbau einer solchen Anwendung vorgestellt und der Unterschied zu anderen Frameworks erläutert.