However, function objects, sometimes referred to as Niebloids, after Eric Niebler who pioneered their use in the Ranges library, are still few and rarely composable. With function objects we can send functions, and even complete overload sets, as arguments to other functions, return them, and combine them.

I will show you compositions I want, how to write them and with
gradual scope creep end up with a very powerful set of utilities that are easy to use and require surprisingly little code when using recent additions to the C++ language.

Talk (60 min)

Creating Composable Callables in Contemporary C++

Technique

This talk shows the risks involved in inappropriate integer operations and the problems with integral promotion and the "usual arithmetic conversions" that in addition to the original operands types can further confuse programmers.

We will take a look at MISRA C++ guidelines with respect to integer arithmetic and operations and see where are their limitations in static analysis.

However, the power of C++ and new standard library features will allow us to implement safer alternatives. It might be a bit of art required to actually achieve syntactical nicety, efficient implementation and well-defined behavior when dealing with whole numbers and integers.

Note: this talk will not include approaches for unlimited precision arithmetic that might be required for some domains.

assess the risk of integer arithmetic quiz

why are there hidden problems, shouldn't integers just wrap?

options for dealing with inaccuracy (overflow)

convenient, safe, efficient: can we have all 3?

int != safe && int != ℤ

In this session, we'll revisit some of the guidelines along with code samples in living languages (C, C++, Rust and Python), to see what has aged well, what has not, what we have learned and, perhaps more significantly, what we have forgotten and failed to learn that still applies in code we write or generate today.

The Elements of Programming Style

Testing

Tools

Python

Rust

Language

In this talk, we’ll take a close look at the Decorator and Adapter design patterns. Both are very commonly used — there are for instance various applications within the C++ standard library — and both have clearly defined applications and responsibilities. However, since they are structurally similar, they are often confused — even in the standard library.

In this talk we’ll shed some light on these two design patterns and their misconceptions. We’ll see several examples of them, also within the C++ standard library, and learn how to properly distinguish between them.


Design Patterns - The Most Common Misconceptions (3 of N)

While some of that is - at least with current compiler technology - inherent to C++ due to its accrued complexity, expressive power, its legacy, and the preservation of former investments (a.k.a. "backwards compatibility"), there are language features that can slow down compiler throughput, but also other ones that may improve it.

There are pitfalls to look out for, and techniques that you might want to take advantage of to improve your - and your teams! - developer life. Beyond more generally applicable advise to everyone, I will show some tangible results from whole in-house applications that drive the machines we build. Maybe some of that will give you ideas that you may want to employ in your codebase.

Same C++, but quicker to the finish line

In this session we'll familiarize ourselves with the Language Server Protocol (LSP), with some real examples from real code editors as well as looking briefly at the specification. Next we'll consider what this protocol enables us to do, and even how cool projects are using it for our coding pleasure!

A bird's eye view of a language server

With four kinds of loops, ranges, and even the infamous goto statement, there’s a lot more under the hood. Add to that the variety of collections – vectors, maps, stacks, and more – and each can require a different iteration technique. Some patterns are less efficient; others may introduce subtle, hard-to-detect bugs.


But iteration in C++ doesn’t stop with conventional loops. What happens when you need to iterate over a variadic parameter pack or a heterogeneous container like std::tuple? These situations require more advanced techniques, and standard patterns often fall short.


In this talk, we’ll explore the full spectrum of iteration in C++. From basic constructs to powerful metaprogramming idioms, we’ll revisit this fundamental concept with fresh eyes.

Iteration in C++: From Regular Loops to Powerful Metaprogramming Idioms

Vyacheslav would like to go into details of a secure boot workflow and what is required on STM32MP15 platforms to implement it. The talk covers important software components required for a proper verified boot implementation, in particular Trusted Firmware Arm (TF-A), Trusted Execution Environment (OP-TEE), and a Flat Image Tree (FIT).

Practical Security on stm32mp1 Platforms

Platform

Security

The talk is meant to be interactive — the audience will be invited to guess the output of short code examples before they are revealed, hopefully giving people a few surprises and making the lessons stick better.

Through these examples, the talk covers how lazy evaluation works under the hood, why the order of view composition has real consequences, and how filter's caching of begin() can produce results that catch even experienced developers off guard.

Composing transform and filter in the wrong order leads to unexpectedly frequent function calls; introducing mutable state into a filter predicate produces stranger results still.

The goal is an audience that leaves with both a solid mental model of view pipelines and a healthy respect for what "lazy" really means in practice and what you should - and more important - never should do with a filter view.

This talk has not been presented fully before, but is based on a similar interactive talk I held back in 2024 for reMarkable guild-cpp. I will link to the presentation used there, with a few added pages indicating some of the additional talk points I plan to add.

The actual description to be used for NDC could be someting like:

Modern C++ ranges and views offer a powerful, composable way to work with sequences of data — but they come with subtleties that can surprise even experienced developers. In this talk we'll explore std::ranges::views, with a focus on filter and transform. Along the way, we'll pause and ask: what do you think the output will be?
Through some examples, we'll uncover how lazy evaluation actually works under the hood, why the order of view composition matters more than you might expect, and how filter's caching of begin() can lead to surprising results.
The goal is an audience that leaves with both a solid mental model of view pipelines and a healthy respect for what "lazy" really means in practice — whether they are encountering ranges for the first time or thought they already had them figured out.


C++ ranges - demystifying filter and transform

This talk takes a tour through some of those gaps. We'll look at concrete examples where the language permits what programmers don't expect, walk through the historical workarounds (deleted overloads, SFINAE, concepts, sanitizers, contracts, guidelines), and ask a recurring question: when can these gaps be closed by libraries, and when do they require the language itself to change?


We won't solve C++. But we might leave with a clearer sense of which problems are accidents of history, which are deliberate trade-offs, and which are still genuinely unsolved.


Some familiarity with modern C++ is assumed.

When C++ doesn't mean what it says

Some sanitizers require you to rebuild your dependencies, but others don't. Why is that? How on earth can AddressSanitizer detect uses-after-free if deallocations in your dependencies aren't instrumented?

In this talk we'll look at how two commonly used sanitizers, AddressSanitizer and ThreadSanitizer, work under the hood. This will give you a better intuition for how to work with them, what kinds of errors you can expect them to find, and how to better interpret their results.

We'll also see why AddressSanitizer works even if you don't rebuild your dependencies, while ThreadSanitizer doesn't, and we'll see what you can do work around this if you're not able to rebuild your dependencies with ThreadSanitizer yet.

Finally, we'll see a practical example of how to configure Conan to automatically re-build and re-use dependencies for sanitizers.

After this talk, you'll not only know how to use sanitizers in practice, but also better understand their output and how to interact with them.

How Sanitizers Work

Each example of illustrative pseudocode and patterns will focus on branch prediction and elimination. Yes, they're microbenchmarks. But they expose patterns that show up in real systems, especially when profiling points to control flow as your bottleneck.
Examples will use animated visuals, annotated assembly, and performance counter data to explore how modern CPUs handle control flow. We'll look at different architectures: from out-of-order x86 cores to in-order ARM and embedded processors to see how each behaves under pressure. We will also look at how different popular compilers, from GCC to MSVC, transform the same source code in surprisingly different ways.


Through these examples, we’ll dig into branch prediction and the costs of misprediction, indirect calls and virtual dispatching, conditional moves versus branches (including when and why compilers tend to emit CMOV and when they don't), and more! Each example will be connected to real world trade-offs: what -O2 and -O3 already do for you, determinism and worst-case latency concerns, code size constraints in certain systems, and why the same branch can behave very differently across a variety of architectures.
We’ll measure hardware, inspect branch counters, and discuss how to design trustworthy microbenchmarks without fooling ourselves.


These examples will come from real-world production scenarios that have surprised even experienced engineers. The talk has been refined through multiple internal runs and fits comfortably within the allotted time. While examples are shown in C++, the principles apply to any language targeting modern CPUs.
Attendees will leave with:


A concrete mental model of how branches behave on real processors

Practical patterns for reducing mispredictions and improving worst-case latency

A clearer understanding of when not to micro-optimize

The confidence to validate changes using proper profiling tools

Are You Smarter Than A Branch Predictor?

As an Engineering Manager, how deep should your understanding of the systems that your team members are building go? How should you balance system architecture and design, code review, debugging, project management, mentorship and caring for your people?

And the perennial question - how much code should you be writing?

I don't pretend to have all the answers, but what I can bring are personal reflections from 20 years of managing high-performing software engineering teams alongside my 45 years of coding.

Becoming an Engineering Manager Without Losing Your Technical Soul

I will examine the practical implications, at the code level, of testing for “right-ish” and “wrong-ish” using small machine learning models. We can usefully bring in openness and learning into a space previously dominated by closed, idempotent logic. The examples we consider will reveal that this is a watershed change radically altering how test-automation code looks and works.

I have long been focused on other attributes of automated integration and end-to-end tests, beyond just passing and failing. These attributes include different meaningful test trends calculated over time. This talk will pick up that thread again because the move toward less deterministic tests I present here puts real pressures on test result management. But solving that problem also gives us an exceptionally relevant advantage in our current dilemma of accelerating A.I. generated pull requests: a stochastic approach that pinpoints the most likely acute failures may be the only way to rescue quality in the face of an A.I. generated code onslaught.

Writing automated tests in the age of probability

Over the past few years, part of my work at Qt has been helping push Qt Quick toward becoming a solid option for desktop applications. One example of that is adding windowing system–level popups. https://www.qt.io/blog/popups-and-menus-in-qt-quick-6.8

In this talk, I’ll walk through how that feature came to be, the unexpected problems along the way, and what it took to make it work across different platforms.

Most of the technical deep dive will be around how windowing systems behave in practice, where platforms differ, and how those details surface inside Qt’s internals when you try to build something cross-platform.

Windowing systems, and what I learned from adding popup windows to Qt Quick

The challenge that we'll face in this talk is that of taking existing concurrent and systems which were not originally designed with Structured Concurrency in mind, and making the gradual changes towards that design and towards more natural use of senders, receivers and coroutines.
Join me in a tour of various techniques and tips for modernizing legacy concurrent systems, as we prepare for adopting the C++26 standard.

Refactoring Towards Structured Concurrency

The project puts considerable effort into ergonomics, which translates into two questions: Can a Rust API represent the many C++ concepts accumulated over the years without leaking its heritage everywhere? And can this API be "safe" enough to free users from littering their code with unsafe blocks? We consider both essential for a truly ergonomic API.


In this talk, we present our greatest hits of whack-a-mole with raw pointers, wrapping wrappers to hide C++ from our users, and wrestling with Rust concepts that don't survive the language boundary. We explore what "safe" means in terms of Rust and whether a library built on a substantial C++ backend can ever truly claim to be so. We'll show off what works, own up to what doesn't, and share what keeps us up at night.

Can a Rust API for QML Be Ergonomic? And "Safe"?

Using strict languages (the Rust compiler is the cheapest and fastest sanitizer you have access to!) is essential.

Aggressively pushing higher (90%+) coverage with fuzzers, mutators and general branch coverage is unfeasible for human developers, suddenly becomes mandatory for AI code!

Will also mention the importance of a good plan up front, and the importance of clearly stating what the acceptance tests look like for any feature, and how focusing on testable architecture helps keep things under control.

Aggressive trust building with Rust in the age of AI

Hopefully, the author had written a GDB extension to pretty-print their data types. But odds are, they didn't. As library writers, or as people writing classes for others to use and reuse, we can and should be writing debugger visualizers. We can empower our users by lowering the barrier to using the library successfully. Let's make our libraries more accessible. Software is about more than just the source code.

This talk will help you make the most of GDB extensions. After briefly discussing how to get started with GDB assuming zero prior knowledge, we will discuss how to write a GDB pretty-printer, how to set up your system to use the pretty-printer, how to embed it into your compiled binary, and how to distribute it with auto-loading scripts. By the end of the talk, the user will not only know the basics of writing a simple "to_string()", but will also understand how to effectively display containers and how to implement custom debugger-side user-facing extension methods. Let's get excited about debuggers!

Prioritizing Pretty-printers

In this talk we'll discuss some common challenges faced in Multimedia when we attempt to make several platform backends behave similarly, such as:

- The pipeline necessary for starting camera/microphone recording
- Platform specific caveats: GStreamer, Android, iOS, WebAssembly
- Programming patterns and algorithms that have proved useful
- Testing of multimedia functionality

Qt Multimedia: Building simple public APIs with complex backends

Given that the target audience is predominantly SW-engineering focused, a reasonable starting point would be to discuss the time domain differences if compared to HW-engineering. Software is inherently serial, if you have a set of entities – those entities will be dealt with serially in separate instances of time. Hardware view is much more parallel – a set of entities will be dealt with at the same instance of time, even if there are dependencies among those entities. This difference in viewpoints often is the limiting factor in trying to switch the brain from SW to HW engineering mode. Then it is time to introduce combinational and sequential logic, a concept of state machine and its equivalence to memory-backed variable in sw domain, and then move to deeper aspects of internal FPGA functional blocks. An important aspect to mention is that even if one sees an FPGA as an unordered set of logical elements, it is not a direct equivalent of sea of К155ЛА3/7400 gates, and soldering a capacitor to an FPGA directly would not result in an equivalent of a clock generator. 

Discussing the underlying LUT plus fixed logic elements and their interconnections should be done in the context of what could be mapped to FPGA-based designs easily, and what would be hard to achieve, with some quantization of what ‘hard’ and ‘easy’ mean here and in what dimensions they are measured. Having much of the focus and time on hardware description DSLs might not be too practical – at the end that is just a tool to express for expressing the intent, and the intent is mostly constrained by how well it maps onto the FPGA structure, and much less depends on the specifics of the DSL. If the intention is to touch the ASIC topic, it seems reasonable to address the differences in logical and physical HW implementation layers – the soft and hard functional components (ie, you can implement a processor core based on the logical elements of the FPGA itself or use a separate fixed structure core provided as a separate logical element – both having exactly same ISA and external behavior characteristics, but a vastly different performance), and library vs custom based topology components for ASIC layout – again, the discussion of performance characteristics and the quantization of dimensions of those characteristics. A good subtopic to mention would be on the industry trends and why FPGA-derived programmable logic structures are becoming more relevant in the context of generic compute platforms.


An important observation is that an FPGA does not operate in isolation – it has external interfaces to other components, and a large part of complexity related to system level design comes particularly from the specifics of those interfaces.


Hardware for software engineers

This talk explores how we built it in Rust, covering our hardware and platform decisions, and how we created what we believe is the first IEC61508 certified product based on the language.

Rust for Safety

Product

In this session you might learn a bit more about development boards, device datasheets, emulators, machine code, assembler, unprotected direct memory access, cross compiling, and just having some fun with writing and running code directly on the bare metal.

Introduction to Bare Metal Coding

Keynote

Complimentary food and drinks will be served. 

 Conference reception with food and drinks

1 Day

NDC Party

However, all this falls apart if we need to access a system with no network connection. These could range from low-end small IoT devices to even high performance servers with a broken or a misconfigured network card. Such systems usually only provide access via a serial port (or a similar text based interface) or emulate a browser-based KVM (keyboard-video-mouse). So to authenticate one needs to actually type something in and most text based authentication is still relying on plain old passwords.

Password-based authentication has some security challenges: passwords may leak, may be cracked and need to be rotated periodically. Wouldn’t it be great to be able to just use the same secure cryptographic authentication as in SSH for text-based logins? This presentation proposes a protocol and an implementation on how to reuse existing SSH keys for text based authentication. We will also explore how to further enhance the security of the solution by using hardware-backed SSH credentials.

sshlogin: securely authenticating to remote Linux systems via a serial or a text-based interface

You may know C++, but how do you get started in the specifics of a given domain with its own established codes and patterns? Where do you learn best practices? How do you deal with the prevalence of C-style thinking? Can modern C++ feature help? How quickly does the word "modern" loses its meaning in tech literature?

We will answer all those questions, and more! And since we're talking about graphics, we might even see some cool shader magic if time allows.

Learning Graphics Programming with C++

Modified Condition/Decision Coverage (MC/DC) is a coverage metric that focuses on the structure of the decisions (ifs and ors) and requires not only that both then/else are entered, but that all conditions are meaningfully tested. It is a useful tool for testing guidance, flaw detection, and high-quality test suites like SQLite's TH3. It is particularly important in safety oriented industries like automotive, aviation, and spaceflight.

This talk covers MC/DC from the ground up; its history and use in the industry, how it improves on weaker forms of coverage, how to properly understand and intuit it, and how to do it with tools today. We will look at code, tests, diagrams and graphs, and maybe peek under the covers and see how GCC measures coverage (I wrote the MC/DC support in GCC).

Mastering MC/DC from first principles

But there are many other member functions, in the form of comparison operators, that we can =default explicitly

Which of these should we =default? How do we help the compiler, or stay out of its way?

How many do we need to implement? When can you trust the compiler or not?

Rule of 0,1,2,5,6,7,8,9,10?

In this 60-minute story-driven adventure, we’ll meet the most common (and mischievous) concurrency bugs in modern C++. We’ll explore how they sneak into everyday code and why they’re so good at hiding. Expect playful examples. No silver bullets — just a friendly map of the concurrency monster zoo. You’ll walk away a little braver… and your threads a lot better behaved.

Once Upon a Thread

In this session we will investigate how to build complete interactive programs such as games and UI-driven applications, still without ever booting into your regular operating system. Learn what is possible as we throw away some tens of millions lines of code we have learned to depend and rely on every day!

We will utilize UEFI-complient systems, allowing us to boot it on any compliant PC system / emulator (e.g. qemu). We'll use the system level languages Zig and C for the examples.

Bootable applications - fully interactive programs

In this presentation the speaker will share the lessons learned on a large scale, high performance, C++ application that had to be brought in quickly to better standards, including having significant automated tests where there was none. We will discuss the tools used, the approaches taken, the myths that had to be fought, and the results that were achieved through hard work and some help of AI.

 Creating Automated Tests for a gnarly application: Lessons from The Trenches

For years, "wait for compiler support" was a reasonable answer. Not anymore. GCC, Clang, and MSVC have all shipped modules support, with caveats. The question has shifted from *can we use modules* to *how do we actually introduce them into a real codebase*.

Porting a cross-platform project is a different exercise than understanding modules. What lives inside that gap is not in the tutorials. Some things break silently. Some break loudly. Some design decisions are hard to reverse once you've made them. And the compiler behavior you will hit in practice diverges in ways that will matter to your project.

This talk is a practical porting guide built from experience migrating real C++ codebases where supporting multiple compilers simultaneously is a hard requirement, not a nice-to-have. You leave with a migration strategy you can apply to your own codebase and a clear picture of where the toolchain is ready and where it still isn't.

How to Port Your C++ Codebase to Modules

In this talk we take a deep dive into the first one.

We start by looking at the simplest motivational example: a rarely updated config that is read by many threads.

Then we go through rcu implementations, progressively adding more and more interesting features and requirements.

While building rcu, we talk about the very low level concurrency primitives, including newer ones, such as asymmetric fences and atomic wait/notify.

I'll also briefly cover the hazard pointers API so you leave with a complete picture of both C++26 primitives.

How to implement C++26 RCU

We'll walk through a real-world implementation on Rockchip boards running Yocto and Mender with A/B flipping, demonstrating automatic LUKS unlock backed by OP-TEE. You'll see how standard Linux tooling (cryptsetup, systemd-cryptenroll) works with the fTPM TA, providing hardware-backed key storage.

Hardware-Backed Secret Storage on a Rockchip with OP-TEE as a TPM

The talk covers Rust language features, pre-silicon software development on simulators, safety certification requirements for automotive software, tools setup, how Rust can potentially help reduce the certification burden etc. We will discuss a few language features that makes Rust pleasant to program. The talk will also try to cover certain social aspects like convincing people to switch languages and convincing certification authorities on how Rust is not C, training developers, convincing management etc.

Experience writing Root of Trust firmware for automotive SoC in Rust

We'll briefly revisit the "dark arts" of early reflection techniques, from preprocessor tricks to SFINAE gymnastics. Then we'll dive into the design of static reflection in C++26, showing how it enables real compile-time introspection and code generation.

By the end of this talk, attendees will have a clear overview of the evolution of reflection in C++, an understanding of the capabilities and design of C++26 static reflection, and insights into how to leverage this powerful feature in their own projects.

Vampires Begone: A Journey Through the Evolution of Reflection in C++

Often, ABI is implicit and often unconsidered – but never untouched. It is
everything we do. This talk will run from the early world of massive Computers, filling a room (or multiple), running calculations with FORTRAN or COBOL, simple batch processing operating systems; then onto minicomputers, ALGOL, C the world of time sharing and UNIX; and finally our modern world of microcomputers and the languages and systems that we use every day.

We will discuss decisions taken by operating systems, languages, and computer designers across the decades to create the ideal binary interface – or at least, the best compromise. I hope that this talk will give you a renewed
respect for the people who helped design the world you live in, and the machines you work with.

 A People's History of ABI

At the end, we'll be able to serialize and deserialize structs and enums, supporting any configuration of endianness and relative pointer size using generics, all without any copying or allocation.

Implementing zero-copy (de)serialization in Rust from scratch

After the introduction of event driven systems I present about different approaches on how to deal with these systems, from simple approaches like sequential processing in an infinite loop to asynchronous and multi-threads approaches.

Patterns for Event Driven Systems in Rust

Starting with a URDF file, an initial UI can be generated, can run and connect to the robot immediately, then you can customize further from there to develop a complete "digital twin" or "teach pendant" UI.

Introduction to Qt Robotics

After delving into some of the common problems with legacy modernization, we'll start tackling the simple "boring" stuff that deliver huge leverage of changes via clang tooling. These represent repeatable, deterministic reviewable upgrades that can be automated and applied at scale.

Then we can look at more difficult transformations that can be AI assisted with more aggressive transformations including API improvements and how to prevent it going off the rails. This will be backed by Compiler diagnostics, static analysis and testing to keep changes maintainable and correct.

The goal is not to replace engineering judgment, but to accelerate it: turning modernization into a continuous, low-risk workflow instead of a disruptive project.

Attendees will leave with a repeatable playbook for modernizing legacy codebases incrementally, safely, and at scale—using the right tool for each class of change

Modernizing Legacy Codebases without Stopping the World

Just replacing the global allocator with another one is not always the best/only choice. Long-running processes can quietly grind down when they lean on a one-size-fits-all global allocator. In contrast, in many workloads, local specialized allocators are better suited - allocating memory for a well-defined subset of objects in the system (eg. arena, multi-pool, monotonic).

Let’s analyze various allocation strategies using critical memory performance indicators such as: fragmentability, allocation density, diffusion, variation, utilization, locality, and contention.
Are we allocator-aware yet, in Rust? What does it take to stabilize the allocator API, so we can unlock these new found super-powers? Let’s walk through some of these challenges.


Allocator-Aware Rust

Often, these crashes are not caused by local bugs. Instead, they arise from the way our program is composed. The root cause is usually an ABI incompatibility or an ODR violation.

In this talk, we’ll look at a practical example of how ODR violations can creep into our software systems. We will revisit fundamentals such as static and dynamic libraries, linkage, and symbol visibility, and discuss how to design our components and compose our systems to make them more robust against this class of bug.

Another Kind of Bug - The Subtleties of ODR Violations

A talk about the lessons learned while building an embedded system at a pre-seed startup, with limited senior oversight and learning on the job. We discuss how we made a reliable embedded system with no prior industry experience, the factors that have enabled us to arrive at a working pilot deployment, and the modern tools that we apply to iterate quickly.

Thriving in deep water: Building a submerged embedded system from scratch with no experience

Let's share a couple of stories about what it takes to embrace Rust in the industry. What are the gaps, the needs, the tools we needed to reengineer for Rust, to make it fit into a world that has never seen the likes of crabs?
2026: Are we Rust yet? What are the lessons learned from building & shipping Rust, what was the impact of some of the strategic Rust bets, what's working great in practice, what needs to be improved. Let's chat.

Panel: Rust (in production) Without Fear

An unusual talk about programming, postmodernism, communication, functions, and who knows what else.

NDC { TechTown }

Agenda

09:00 - 10:00 (UTC+02)

Keynote

Hana Dusíková

10:20 - 11:20 (UTC+02)

How Sanitizers Work

Anders Schau Knatten

Becoming an Engineering Manager Without Losing Your Technical Soul

Paul Williams

Hardware for software engineers

Ignas Bagdonas

Aggressive trust building with Rust in the age of AI

Mathias Myrland

C++ ranges - demystifying filter and transform

Ole Bøe

11:40 - 12:40 (UTC+02)

Are You Smarter Than A Branch Predictor?

Michelle D'souza

Can a Rust API for QML Be Ergonomic? And "Safe"?

Matthias Rauter

Qt Multimedia: Building simple public APIs with complex backends

Nils Petter Skålerud

Lars Sutterud

Creating Composable Callables in Contemporary C++

Björn Fahller

13:40 - 14:40 (UTC+02)

Design Patterns - The Most Common Misconceptions (3 of N)

Klaus Iglberger

Iteration in C++: From Regular Loops to Powerful Metaprogramming Idioms

Vitaly Fanaskov

Writing automated tests in the age of probability

James Bornefelt Westfall

A bird's eye view of a language server

Joakim Lier

Introduction to Bare Metal Coding

Olve Maudal

15:00 - 16:00 (UTC+02)

Same C++, but quicker to the finish line

Daniela Engert

Practical Security on stm32mp1 Platforms

Vyacheslav Yurkov

Prioritizing Pretty-printers

Braden Ganetsky

Refactoring Towards Structured Concurrency

Roi Barkan

16:20 - 17:20 (UTC+02)

The Elements of Programming Style

Kevlin Henney

When C++ doesn't mean what it says

Giuseppe D'Angelo

Windowing systems, and what I learned from adding popup windows to Qt Quick

Oliver Eftevaag

Rust for Safety

Espen Albrektsen

int != safe && int != ℤ

Peter Sommerlad

17:20 - 21:30 (UTC+02)

NDC Party

Anders Schau Knatten