Talk (60 min)

Cache friendly data + functional + ranges = ❤️

Technique

But C++ has evolved considerably since then and, despite what you might have heard, mostly in ways that make it safer and simpler to use.

This talk takes us on a tour of the evolution of C++ - from it’s genesis, following the PhD thesis of Bjarne Stroustrup - up to “modern” C++20 - and a look ahead at what C++23 and beyond may bring.

The question is: is it too late to prevent C++’s decline into being “the next Cobol”?

Not your GrandParent’s C++

Language

In this talk, we explore a number of C++ Core Guidelines and other best practices and compare them to the form in which they have appeared in actual project style guides. We will compare the original intent to the effect of their application in those instances. In the end, we will draw conclusions how guidelines should be chosen and applied to projects to get the most benefit out of them without bogging the team down with needless bureaucracy.

Core and other guidelines. The good, the bad, the... questionable?

This talk dives into several of the near-fatal accidents of early crewed spaceflight, including Gemini 8, Apollo 11, and Apollo 13, and focuses on the system design choices that averted catastrophe. Topics include failure modes, process prioritization, recoverable software, levels of autonomy, and designing for human intervention.

NDC Party: Architecting Apollo: Systems Design Lessons from the Golden Age of Spaceflight

Product

These topics have been quite popular in the C++ community for the last five years or so. However, many of them are focused on theoretical parts, have only small non-related examples, or even use other programming languages to illustrate the ideas.

This talk is prepared based on more than one year of using functional programming approaches for developing one of the commercial internal libraries our team is working on. I’m going to share this experience with the audience. We’ll talk about API design in general, spitting between pure and impure context, and the pros and cons of using “optional” and “expected”. There will be real code examples and some useful tips.

This talk will be useful for software engineers who want to start using monadic operations in their everyday routine or for those who already do it (at least partially) and want to learn more about that.

Monadic Operations in Modern C++: A Practical Approach

Path coverage in gcc

Tools

Reflection/injection - facilities for extracting information from the program, performing compile-time computations based on that information, and injecting new program entities based on those computations.

Pattern matching - a new expressive selection mechanism that matches values against patterns and binds variables when matches are successful.

Senders - a framework for asynchronous programming that enables us to write generic code that can run on any type of execution resource, from a single thread to a cluster of GPUs.

Come to this talk to find out what's on the horizon for C++, how it will change how you code, and why you should be excited about it.

C++ Horizons

I have done all of these things more often than I would have liked in the past and I had acquired a solid understanding of x86 assembler code over the years. All was well until, suddenly, I had an ARM machine on my desk.
If you are, like me, using ARM machines a lot and always wanted a gentle introduction to ARM assembler code, this is the talk for you.

Passive ARM Assembly Skills for Debugging, Optimization (and Hacking)

Platform

Sharing data in multi-thread programming may be tricky and there are plenty of options on how to deal with it. You should always go for the simplest possible scenario to not end up in trouble.
In this talk we will build up the whole story from illustrative examples which will allow us to understand all synchronization primitives available from C++ 20. We will also uncover what the memory model is and why we need it.

At the end, you should be able to spot problematic code parts, easily decide which synchronization technique to use and reason about it.

Memory Model: Get your shared data under control

Dependency Injection (DI) is a design pattern fostering loosely coupled code by separating components from their dependencies. We'll delve into various DI types in C++, such as constructor, setter, interface, and template injection, exploring their use cases and best practices.

Despite C++ lacking native reflection support, we can achieve dynamic analysis and manipulation of class structures through introspection techniques like type traits, constexpr functions, and variadic templates. Template metaprogramming, complemented by features like SFINAE and type deduction, extends the capabilities for introspection and reflection.

Furthermore, we'll examine how the fusion of Dependency Injection and Reflection can facilitate extensible and adaptable software architectures. Leveraging libraries to simulate reflection and dynamically resolve dependencies enables a more flexible DI setup, easing the integration of new components into existing systems.


Exploring Dependency Injection and Reflection in Modern C++

* in C++'s standard library and few more...

My favorite data structures

In this talk, I aim to unravel the complexities of process address space using the Linux kernel as an example.

Demystifying Process Address Space: Heap, Stack, and Beyond

That's the opportunity offered when you set up a startup. But it turns out that it is not all straightforward. There were good reasons behind some of those annoying choices and now you get to discover what they were.

This talk will focus on experience gained at a software product startup over a twelve year journey from inception through stock market launch to maturity. It will also draw from my previous, less successful, forays into the startup world.

This won't be a talk focusing on language choice or the benefits of one Agile methodology over another. We are going to look at the fundamental issues at the heart of developing a software product and try to arrive at a consistent approach to resolving them. This will guide our decisions as we develop our individual approaches to software development.

Even though we won't all get, or want, the opportunity to start with a clean slate, taking that thought experiment into a mature product development group can reap insights and benefits.

A Clean Slate

And in many cases applications requiring sensor processing can be solved faster and better using machine learning techniques. This talk explains the why and how to use machine learning on microcontrollers.

Using machine learning to save power and development time

The main body of the workshop will comprise running Cosmic Ray on a provided project. This will ensure that we can see all of the important elements of the system while avoiding the complexities of working with unknown code bases. With that said, if you want to try running Cosmic Ray on your own code as well, we can try that, too.

If time permits, we can also look at topics like creating new mutation operators and integrating Cosmic Ray into continuous build systems. Ideally, we’ll work through the main portion of the workshop with enough time for students to explore Cosmic Ray on their own, so come prepared to experiment and explore!

Mutation Testing in Python with Cosmic Ray

Testing

Python

In this talk, we'll discard all abstraction layers to uncover the intricate details of our CPU, whether they are disclosed or not. Through hands-on reverse-engineering techniques focused on a specific x86 CPU, we aim to unlock significant performance enhancements for our code. While our focus is on an x86 architecture, these techniques are transferable to any type of CPU and architecture. After this talk, I hope you see reverse engineering as not only insightful but also downright fun!

Unlocking Performance Through Reverse Engineering

In the first part of this talk, we review some examples of C/C++, both single- and multithreaded, including a common lock-free algorithm. We examine the compiler-generated Assembly code and gain an intuition for how much reordering the compiler and the CPU are allowed to do. We then discuss what C++ means by a data race and how to avoid them using atomics and memory orderings like sequentially consistent, relaxed, acquire, and release. We also see how C++ reasons about memory ordering in terms of happens-before relationships.

In the second part of the talk, we examine the CPU memory models and what we mean by reordering of memory operations. There are many sources of reordering, such as the compiler, the CPU pipeline, micro-ops, memory systems with store buffers and coalescing, caches, etc. We then see how CPUs reason about memory ordering differently than languages like C++ and Rust and how the CPU memory models enable the language memory models to work. We also see how x86, ARM, and RISC-V have different approaches to this.

At the end of this talk, you will have gained a better understanding of what guarantees your programming language gives you and how the CPU works under the hood to allow your programs to (safely) go vroom! You will also have learned not to make assumptions about the correctness of your code by simply looking at the Assembly code.

The Two Memory Models

As software developers, one of our tasks is to ensure intuitive operation - regardless of the language the user (or compiler) understands best. Otherwise, the risk of errors increases and operational safety may no longer be guaranteed.

National language adaptations - possibly dynamically at runtime - appear to be a solved problem area. There are libraries for this. However, if you want to use them together with std::format or std::print, you will realise that none of them allow translation at runtime, because the format strings must be C++ literals! The compiler analyses these during program translation in order to detect errors in the use of formatting instructions and argument types. This is one of the main advantages of std/fmt formatting over the other options, which only detect errors during runtime!

I am currently developing a library for our company's machines that allows error detection at translation time, but still allows dynamic translation into the user's preferred language.

Human languages do not always follow immediately recognisable rules, e.g. when it comes to the correct choice of a linguistic form in connection with statements about several things. The Unicode Standard describes such rules in machine-readable form, which the library uses to provide the correct translation.

For the implementation of the library, it is crucial to convert known idioms from the programming of runtime code into semantically correct equivalent code for execution at translation time. Despite 'constexpr', some code looks unfamiliar at first when it is translated into the language of execution at compile time.

In the course of the presentation we will therefore talk about:

a widely used system for language translation

existing libraries for this and their APIs or embedding in the build process

differences and similarities of code execution at runtime and translation time

the 'language rules' for translation between the two

Code excerpts from my library serve to illustrate the points mentioned.

Not getting lost in translations

This talk describes the problems with this approach and a better approach for achieving safety and portability.

Correct Use of Integers in Safety-critical Systems

Security

Topics to be covered:
1) How software development has changed over the years
2) How software development is the same 45 years on
3) The importance of testing at various integration levels
4) What we learn from disasters and near-misses
5) Why spacecraft software has to be "better" than other embedded software
6) The future of embedded software as it relates to human-rated spacecraft
7) Pictures, videos and other interesting tidbits of Shuttle and Orion flights
8) Questions answered

Contrasting Embedded Software Development for the Space Shuttle and the Orion MPCV

Beyond introducing Carbon's milestones, we'll share what we expect to get out of this release and what C++ developers can expect when using them. The talk will dive into the specific parts of Carbon's 0.1 milestone that are already shaping up and show how they are working in practice, including demos of the Carbon toolchain and compiling small, early, but working Carbon programs. We will also outline the remaining path to actually completing 0.1 and getting it into the hands of developers. And last but not least, we'll share a preview of the incremental evaluation and adoption workflow we are envisioning for existing C++ developers and codebases.

The Carbon Language: Road to 0.1

But despite their fundamental importance, there are some common misconceptions about them, in particular about several of the most often used design patterns:

The modern form of the Visitor design pattern, std::variant, is often considered a replacement of virtual functions.

The Decorator design pattern is sometimes mistaken as the Adapter design pattern.

The Chain of Responsibility design pattern is often confused with Decorators.

Explicit object parameters (“deducing this”) is often named as a modern, better form of CRTP.

In this talk I'll shed some light on these misconceptions and explain how to properly distinguish between the different
design patterns.

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

(TBD) About Supply Chain Attacks

Let’s see if and how the modern C++ tooling can address the things that frustrate C++ developers the most. We’ll cover things from package management, CI setups, and development environments, to CMake debug and profiling, and a bit of data flow analysis (DFA) to statically identify many sources of undefined behavior and potential vulnerabilities.

Keynote: How To Address 7 Major C++ Pain Points with Tools

Deep dive with Blueye underwater drones

Introduction to eBPF

In this session, we walk through how to design a new language feature in an older language like C. We discuss technical constraints, existing implementations, user expectations, and ways to understand and handle the complexity of allowing for e.g. adding 2 "vec3"s together. We discuss algorithms for how to match arguments to functions, and ways to achieve this without the typical, potentially binary-bloating techniques that C++ or Rust have to deploy to get the same work done.

This feature does not currently exist in C, so this is an exercise in how to engage with designing under constraints (in this case, 50+ years of it) for software developers!

Hello Operator: Making The Call for C

On the other side, this mechanism has been repeatedly used in various vulnerabilities and exploits as a starting attack vector, multiplying the damage and impact of these exploits. And since it became so popular within the offensive industry, many Linux distributions and security guidances started recommending disabling this feature altogether.

There is an ongoing debate whether unprivileged user namespaces provide more security or make the system more vulnerable. In this presentation we will review how user namespaces might help building sandboxed secure applications. But we will also show how a recently discovered Linux kernel bug turned into a security vulnerability just because user namespaces are available on the system. Finally, we will give recommendations on how to get the best of both worlds: allow well-behaved applications to utilize user namespaces for better security, while blocking the feature for potentially malicious users/code.

Linux user namespaces: a blessing and a curse

In this workshop I will show by means of an 'easy' example (Kata) how this can be achieved following a "Metal-In" TDD approach, which can be seen as a Dual-Target TDD specific implementation. This approach is aimed, among other things, to minimize how much hardware gets involved in our embedded code development workflow.

We will first touch the metal, facing its cold truth, till we finally Make-It-Work. Later, we will drive our code 'In', Making-It-Right (enough), while creating our own decoupled and portable entities and business domain model. We will do it safely, iteratively and incrementally,

• Develop a highly decoupled and portable ‘BatteryMonitor’
module following Metal-In TDD approach.
• Highlight the differences between the Make-It-Work phase
(TDD’s Red to Green phases) and the Make-It-Right (TDD’s
Refactor phase)
• Use state of-the-art automated refactoring tools available for
C/C++

Metal-In Test-Driven Development: A Dual-Target TDD approach

Under Linux, applications can pipe data in batches between sockets with the `splice()` syscall. However this is not the only way to splice two sockets together!

Linux also offers another way to push packets between two TCP sockets without exiting to user-space, called sockmap. The mechanism is powered by the built-in logic built in the core network stack and a couple of BPF-based components to drive the operation.

In this talk we will go over everything a user needs to know to get started using BPF sockmap. We will also discuss sockmap features, internal design, as well as its caveats and limitations.

Speedrun through Splicing Sockets with Sockmap

How To Use `constexpr` In C++23

For any software project, the potential presence of certain bugs is a cost-risk-benefit proposition. How much time can one spend to ensure catastrophic failure does not happen?

Property Based Testing (PBT) is a technique which seems to uncover many bugs compared to the effort needed. It can also be incorporated early in the development process which decreases the effort required to debug.

This presentation looks at the hypothesis property based testing tool used in our Scientific Computing team at Equinor. We look at how it compares to traditional testing methods and verification techniques, and how we use PBT in our team.


Omg, how do I write software that isn't a ticking timebomb!?

Remote blinky on nRF52 using Rust

Rust

All good? Unfortunately, not. The iterator concept, which we have been using since the advent of C++, is fundamentally flawed. In particular, some iterators must behave differently depending on whether they are meant to point at an element or at a boundary between elements. So elements and boundaries are really two distinct concepts. In this talk, I will convince you that the problem is real and has practical implications, make a proposal on how to fix it and show how the solution not only fixes the problem but makes for clearer code and prevents mistakes.


Why Iterators Got It All Wrong — and what we should use instead

When are objects created and when are they destroyed?
How does temporary lifetime extension come into play and what changed there recently?
What happens when you `std::malloc` memory and just pretend objects are there without creating anything?
Or worse: You use `mmap()` to read shared memory.
How do unions interact with constructors, strict aliasing, or the "common initial sequence"?
What when you explicitly call the destructor and later re-use the same storage?
What's the deal with `std::launder`, `std::bit_cast`, and `std::start_lifetime_as`?

We'll answer all of those questions and much more.
We'll do that by looking at the C++ standard, old and new proposals, and compiler optimizations.

An (In-)Complete Guide to C++ Object Lifetimes

We'll get a bird's eye view of the steps that we typically see in compilers as well as follow a piece of code through the pipeline to witness the transformations first hand:
From parsing to code generation, with a little bit of optimization sprinkled on top!

A bird's eye view of a compiler

What influences the rising energy consumption and is there something we can do about it? One not so obvious factor is the choice of which programming language is used to write the programs that are used all over the world.

In this talk we want to analyze how the different programming languages influence the energy consumption of the program. We are going to cite studies and do our own analysis using different programming languages, like C++, C#, Rust, Python and maybe more. Energy consumption is defined as run time multiplied by power consumption and our analysis will show the influence of choosing a different programming language for both components of energy consumption.

Green Programming

Are the regulators «out to get» C++? Will they stop here or will this get progressively more serious? Should we migrate to other languages? What does «memory safe» mean anyway? And why not just wait for C++ to become memory safe?

We’ll look at what has happened lately, why this might be happening and what is likely to happen next.

We’ll also look briefly at the feasibility of making C++ memory safe(ish), and if this could stop the pressure to migrate away from C++.

Finally, we’ll look at what languages one might consider migrating to, why that discussion invariably ends up mentioning Rust, and some things to consider if you want start migrating.

The existential threat against C++ and where to go from here

Understanding and unlocking these language features can yield incredible power, which can be used for great good – or great evil. In this deliberately intense session, an expert programmer with a Python experience spanning 25 years, will open the door to four of Python's best-kept secrets, and open your mind to new ways of thinking about programming.

Profound Python: Four deep insights into how Python works

Beyond unit tests: A peek into large-scale automated testing of video conference systems.

Zephyr is more than just a new RTOS “kid on the block” with a cool kite. It is a very modular, highly portable, real-time operating system with an associated eco-system to build secure, connected and future-proof devices.

But what does that really mean? And how does that help you with your product development? What are the actual challenges?

In this talk, we will look at building Zephyr applications, what sets Zephyr apart from other traditional RTOSs/embedded OSs, and how Zephyr supports the development and expectations for connected embedded products.

Building embedded products with Zephyr

In this session we'll dive into this technology and some of its surrounding infrastructure - Magic Trace.
We will live debug and analyze a running application and discuss the merits of this approach versus some other more widely used tools.

The Magic of a Trace

In this talk I will dive into the choices we at Neat have made in our test architecture in order to both preserve and create value for our company, customers and software development teams. 

I will go through detailed, concrete choices in test code and move onward to the organization of frameworks, tools, processes and practices. I will cover the measures we have intentionally chosen in order to catch regressions, reduce false positives, write maintainable tests, understand test results and enable development teams to do their job faster and with increased confidence. While our specifics, embedded software and end-to-end tests written in Python may not match your situation, many of the questions we asked in order to determine the choices we have made are likely to be both relevant and perhaps even unthought for other teams. 

Test architecture encompasses everything from code to more theoretical concerns like enterprise architecture, but with concrete, immediate consequences. Ignore it at your peril or at least come and find out that it’s a rich, challenging and rewarding domain.

Test architecture is a real thing

For the last three years, we have been using vcpkg to build production packages of our libraries across various platforms and to share internal libraries within the company. Vcpkg has served us well for both, but we have discovered many pitfalls along the way. In this talk, I will show you how to avoid them, or at least how to dig yourself out after you've fallen in.


Using vcpkg in anger

How we came to love 🦀 Ferris: cargo cult or real need?
What is it like to come at Rust from two very different directions: C++ and C#? What are the gaps, the needs, the gems and the tools you should know about? Here's a real journey and the various experiments leading up towards the success stories at Microsoft.
Want to compare notes? Let's chat.


Unleashing 🦀 The Ferris Within

This talk will showcase how a single developer's simple crash analysis
side project got the investment needed to transform it into an
indispensable part of our continuous delivery process. By providing
effective communication from anyone to everyone around anything that
may fail, this tool helps us navigate through the labyrinth of defective
hardware batches, failing test pipelines, bad commits, cloud services
having a bad day, and a million potentially loose cables in hardware labs.


Crash and test failure analysis with AI... no wait, ehm, with regexes!

Despite being very powerful, these elements can sometimes lead to designs that trade-off performance gains for increased binary size.And although binary size is considered in most platforms a constraint-free resource, it can pose a great challenge for embedded development.

In this session, we explore some cases where fundamental C++ libraries and code designs run into foul with binary size and how we could develop libraries to achieve more flexibility with these trade-offs.

What if binary size matters?

Join me on the journey approaching zero dependency by writing and compiling an application that supports the BIOS-variant UEFI, allowing us to boot it on any compliant PC system / emulator (e.g. qemu).

Bootable applications - an introduction

This talk covers local reasoning principles and explores conventions and rules to support local reasoning and develop better interfaces and code.

Locknote: Local Reasoning in C++

What can you do to make both aging and programming more pleasant for yourself? How can you help the older people you know, and set up systems that will help you when you need it? When it comes to ensuring a pleasant and long old age, it's not too late -- and it's also never too soon.

NDC { TechTown }

Agenda

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

Keynote: How To Address 7 Major C++ Pain Points with Tools

Anastasia Kazakova

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

Correct Use of Integers in Safety-critical Systems

Robert Seacord

Demystifying Process Address Space: Heap, Stack, and Beyond

Piotr Wierciński

My favorite data structures

Hana Dusíková

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

Klaus Iglberger

Using machine learning to save power and development time

Eirik Midttun

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

Deep dive with Blueye underwater drones

Jonas Follesø

Exploring Dependency Injection and Reflection in Modern C++

Mikhail Svetkin

Passive ARM Assembly Skills for Debugging, Optimization (and Hacking)

Sebastian Theophil

Path coverage in gcc

Jørgen Kvalsvik

Not getting lost in translations

Daniela Engert

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

Cache friendly data + functional + ranges = ❤️

Björn Fahller

C++ Horizons

Bryce Adelstein Lelbach

Hello Operator: Making The Call for C

Björkus Dorkus

A Clean Slate

Giles Chamberlin

Introduction to eBPF

Martin Ertsås

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

Monadic Operations in Modern C++: A Practical Approach

Vitaly Fanaskov

Core and other guidelines. The good, the bad, the... questionable?

Arne Mertz

The Two Memory Models

Anders Schau Knatten

(TBD) About Supply Chain Attacks

Patricia Aas

Not your GrandParent’s C++

Phil Nash

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

The Carbon Language: Road to 0.1

Chandler Carruth

Unlocking Performance Through Reverse Engineering

Patrick Schittekat

Memory Model: Get your shared data under control

Jana Machutová

Mutation Testing in Python with Cosmic Ray

Austin Bingham

Contrasting Embedded Software Development for the Space Shuttle and the Orion MPCV

Darrel Raines

17:40 - 18:40 (UTC+02)

NDC Party: Architecting Apollo: Systems Design Lessons from the Golden Age of Spaceflight

Kyle Kotowick