ACCU 2023 Sessions

We knew that C20 is huge. We introduced several new key features and library that will change the way we use C dramatically (maybe even more dramatically that C++11 did). Of course, not everything is self-explanatory and there are hidden traps.

Now, 3 years later, the big picture becomes clear and the consequences for programming become more and more mature. At the same time, C20 is still changing by applying significant fixes against C20 and standardizing supplementary changes with C++23.

Time to look carefully at C20 (with an eye on C23) to see how all the new features of C++20 (concepts, ranges, views, operator<⇒, coroutines, modules, and compile-time computing support) should be used in practice. It is key to understand all the concepts and their consequences to benefit best.

This 2-day workshop goes through all the major new C20 features (covering both language and library) and provides many examples, unique background information, and advice for the use of C20 in practice. It will cover topics for for application programmers as well as for library developers. The focus is on how these features impact day-to-day programming, what effect combining features can have, and how you can benefit from them in practice.

1-day workshop on C concepts C Concepts is one of the most significant and long-awaited features of C20. They improve template interfaces by explicitly stating the compile-time contract between the user and the architect of the code, which limits the number of compilation errors and makes them much more user-friendly when they occur. The workshop will describe this C20 feature, its similarities, and differences to Concepts TS (provided with gcc-7), and will present ways to benefit from a significant part of the functionality in current production C projects that can use only "legacy" C11 features.

Preconditions to take part in the workshop: 1. Recent working experience with C++ templates 2. A laptop with a web browser and access to the Internet

We knew that C20 is huge. We introduced several new key features and library that will change the way we use C dramatically (maybe even more dramatically that C++11 did). Of course, not everything is self-explanatory and there are hidden traps.

Now, 3 years later, the big picture becomes clear and the consequences for programming become more and more mature. At the same time, C20 is still changing by applying significant fixes against C20 and standardizing supplementary changes with C++23.

Time to look carefully at C20 (with an eye on C23) to see how all the new features of C++20 (concepts, ranges, views, operator<⇒, coroutines, modules, and compile-time computing support) should be used in practice. It is key to understand all the concepts and their consequences to benefit best.

This 2-day workshop goes through all the major new C20 features (covering both language and library) and provides many examples, unique background information, and advice for the use of C20 in practice. It will cover topics for for application programmers as well as for library developers. The focus is on how these features impact day-to-day programming, what effect combining features can have, and how you can benefit from them in practice.

1-day long workshop on Modern C idioms covering subjects like RAII, copy-and-swap, Smart Pointer, type traits, tag dispatch, policy-based design, EBO, Type Erasure, SOO, Copy-on-write, CRTP, CPO, and more. C is no longer C with classes, and it never was just an Object-Oriented language. C is a general-purpose programming language. It has imperative, object-oriented, and generic programming features while also providing facilities for low-level memory manipulation. If used correctly, it provides hard-to-beat performance. Such usage requires a good knowledge of C templates and Modern C++ Idioms, which are much different from commonly known design patterns popularized by the GoF book and invented to handle common use cases in pure OO languages like Java or C#.

What you will learn: During the workshop, we will refresh and broaden our knowledge about C templates and will learn Modern C Idioms like Niebloid, CRTP, Type Erasure, EBO, and many more. Crafting those skills will allow us to build powerful tools that are useful in the everyday work of every C++ developer.

Experience required: In order to be able to follow the workshop, you should be current with C and have some recent experience with writing simple C templates.

Environment: A laptop with a web browser and access to the Internet

This is an all-day pre-conference tutorial. But unlike other tutorials, the Early Career Day is exclusively for software developers in their first years of work, whether as a placement student or a graduate level employee. In the company of others with a similar level of experience, this supportive tutorial will offer you clear and practical guidance in key aspects of your work. Your tutors are well-known speakers selected for their excellent content and clear delivery. If you are wondering if the ACCU conference is for you and how it can help you, this is a great way to try out a 'mini-conference' designed especially for you by experts. The day is chaired by Dr Gail Ollis, an ACCU conference regular who remembers what it was like to attend her first ACCU conference. After a long career in commercial software development Gail turned to academia and is now a lecturer and researcher in software development. Think of this session as a short course in honing your craft as a software developer, with an experienced lecturer as your course leader and the best presenters as your tutors.

The content will include a mix of personal and technical skills, including:

The day includes your very own lightning talk session so you can, if you choose, practice sharing your thoughts at a conference. You are warmly invited to take this great opportunity to practice with a small, friendly, supportive audience, but participation is absolutely voluntary.

In this talk we will explore how different development environments shape the tech we create. Based on Stephanie’s decades of experience, this talk explores development for: research, prototyping, software products, video games, and game engines. There is a common foundation required for building compelling and useful technical solutions. Are there different methods for developing technical solutions in these different areas? Can the same procedures used in software products be used for developing video games? We’ll dive into some of the nuances of how these areas are affected by their different requirements and purposes. We’ll see how the wider context forms the code we write.

There are a many excellent introductions to C20 coroutines. However, beyond the introductory material, there are few examples of how to apply C20 coroutines in practice. This talk goes beyond the introductory material by providing practical examples of how to design, debug and empirically evaluate coroutines. In particular, this talk shows how to develop a coroutine based web-server using CMake and Boost.Beast (with materials available on GitHub) and how this differs from the more familiar event-driven implementation. The performance of a number of approaches is compared and a series of observations are made.

The aim of this talk is to provide practical guidance for how C20 coroutines can be used in real-world applications. The talk begins by clarifying a number of coroutine concepts before showing how coroutines can be used to implement a web-server and how this differs from the more conventional call-back model (i.e. functions/lambdas). The talk will then show how the performance of coroutines can be evaluated and how new features from C23 can be used to alleviate practical concerns. The talk will conclude with an update on coroutines for C23, as well as a look ahead to C26. This talk is suitable for users of all levels who are interested in C++20 coroutines (i.e. sufficient introductory material will be covered to make the talk standalone). The slides and example code will be made available on the author’s GitHub page. <a href="https://github.com/jamespascoe">page</a>.

The C standard defers to undefined behavior (UB) in a variety of situations, embracing the freedom for language implementers to achieve portability across the widest array of platforms. With UB, literally anything can happen, which is the problem; the resulting program has no constraints. As the IT industry needs to broadly embrace security concerns across the whole environment, concerns about specifying UB have grown, and modern languages have tried to avoid falling back onto UB entirely. This session will examine the variety of causes of UB expressed in the C standard, broadly classify them, and suggest different ways to eliminate or mitigate many cases of UB. In particular, we will discuss how the forthcoming work on Contracts might be applied within the language itself to optionally support expensive, but well-defined, behavior in more contexts.

Join me on a tour of some of the more useful C++ Design Patterns that you will likely see and need to know. Knowing how to use Design Patterns will help your code’s robustness and will enable others to better read your code and intent. When designing and writing code you will see similar techniques and patterns repeatedly used throughout different systems and programs. An experienced developer saves these tried and true, well debugged techniques in their personal toolbox for later use.

Others have also noticed these patterns in designs. Some of the more useful techniques have been documented and organized in books like "Design Patterns" by the "Gang of Four" (aka "GoF") and "Code Complete" by Steve McConnell. As coding paradigms have changed new design patterns have evolved.

Other design patterns have worked their way into common use through usefulness. Techniques have been given names for quick reference and as a shorthand in the exchange of ideas. Think of Design Patterns as a mental standard library of building blocks for your designs.

Taking a real world application, it is shown how to properly encapsulate external APIs to protect the system and use modern idioms. How to manage changing requirements including decommissioning of old functionality in the real world. How abstractions can be a powerful absorber of change to limit the impact of changes on a production codebase. Many codebases use external libraries and wrap their associated API’s for application use. Once these external dependencies are entrenched and widely used in your system even small changes in the use of these external APIs can force sweeping changes across your codebase. This presentation will take an example request API and demonstrate using sound engineering choices how to encapsulate it to provide a more efficient modern interface i.e. move-only results, futures/promise instead of callbacks, void pointers etc. After showing the use of this API, new requirements will now emerge that require new source data from the API potentially causing large scale code changes with branching required for a gradual transition from the old data source to the new source is rolled out. We will explore various techniques to preserve the global calling semantics and introduce localized decoupling so wide spread code changes are not needed. How abstractions can be a powerful absorber of change that limit the impact of changes on a production codebase. These codes changes are then transparent to the original callers of the API hence no calling code changes are needed. This approach will then be expanded to apply the same engineering techniques to the unit & system testing code. The final decommissioning and removal of the old code is explored and shown now to be simple and straight forwards. Additional real world problems are then incorporated like batching, parallelization while again localizing code changes on the migration path. This prioritizing of the migration path for introducing API use changes will lead to a novel perspective for the next time your codebase has external dependency changes imposed on it from within or without. This is all backed up with code examples. This alternative approach has being successfully employed for real world situations in Bloomberg

How can a deterministic function possibly give random results? We will find out and learn how to use various random number distributions. We will also discover another way to code ourselves out of a paper bag in the process. Most of us need a random number at some point if we write code. We will discover how they are generated. We will see how to ensure simulating a dice roll makes the numbers 1 to 6 equally likely, and note some pitfalls to be aware of in some programming languages. We will have a brief aside into stochastic outcomes from deterministic models, also known as chaos. Applying a function iteratively can’t possibly give non-deterministic results, right? We shall see. After this aside, we will return to using random numbers. We will consider more complicated situations, such as requiring numbers distributed around an average and how to generate with specific properties, such as being prime. To round off, we will think about how to test code using random numbers. By the end we’ll be familiar with terms like pseudorandom number generator (PRNG), linear congruential generator and random distribution. Finally, we’ll use various distributions to race some blobs out of a paper bag. Seeing a visual demonstration will solidify some the learning outcomes.

This talk is an in-depth tour of the standard attributes currently available in the C and C++ programming languages.

Some attributes such as deprecated, fallthrough, nodiscard, and maybe_unused are very helpful to produce or suppress warnings. Others, such as likely and unlikely, can be used as optimisation hints to the compiler, although it can be difficult to avoid misuse and accidentally pessimise your code instead. The attributes noreturn and assume can even inject undefined behaviour into your code. And then there is no_unique_address, which can be used to optimise the class layout, but comes with its own caveats regarding portability across major compilers.

C has had standard attributes since C11, and every new standard is adding more. The C language introduced attributes in C23, adopted many attributes from C++, and added two new attributes exclusive to C: unsequenced and reproducible.

In this talk, we will describe the syntax and semantics of all existing standard attributes, including the latest additions in C23 and C23, discuss the use cases for each one, show practical code examples, and offer guidelines on how to use them safely and effectively. We will also talk about the often-misunderstood C language design rule that attributes are "ignorable" and what that actually means.

C++20 introduced views, lightweight collections that refer or own collections like containers or other ranges. The design had to deal with several tradeoffs. As a result, the standard views come with so many pitfalls and traps that they are really hard to use for experiences programmers and more or less unusable for ordinary programmers.

Why? How could that happen? How can we deal with what was standardized? Can we do better? Can we even implement or use other views.

This talk will answer all these questions and for sure cause heated discussions.

It is time to have them.

What should you do if you are promoted or hired to be the Head of Architecture in a big, international organisation (or even in a small one)? What should you do to shape the role to deliver value to the organisation and its customers? How do you work with many development teams to shape the current legacy spaghetti mess into a coherent system, without becoming a bottleneck?

In this talk I’ll respond to those questions and more, by sharing my experience in becoming the first Head of Architecture in a big international organisation. What should you do if you are promoted or hired to be the Head of Architecture in a big, international organisation (or even in a small one)? What should you do to shape the role to deliver value to the organisation and its customers? How do you work with many development teams to shape the current legacy spaghetti mess into a coherent system, without becoming a bottleneck?

In this talk I’ll respond to those questions and more, by sharing my experience in becoming the first Head of Architecture in a big international organisation.

Among other things, I’ll share what I did to: - Work productively with the development teams, and be relevant. - Navigate the political landscape to influence decisions. - Create an architectural decision process tailored to the needs of the organisation. - Provide guidelines and constraints to decentralise decision making while avoiding chaos.

The attendees will get a better understanding of what the role encompasses, and future heads of architecture may get a better view of what expects them in this role.

The world is on fire! None of our improvements in software development will matter at all if we can’t change the course of the climate crisis. The software lifecycle creates direct and indirect carbon emissions: it has a footprint, worsening environmental problems. So, it’s time to examine how agility can help to reduce energy consumption and ensure greater - environmental, social & economic - sustainability. The point is not to pursue sustainability for altruistic reasons, but to understand that over time, sustainability is also becoming a key factor that determines the success of companies, both in the search for talent and for customers and markets.<br> In this session, inspect real data to gain a holistic perspective of your team or company’s current situation regarding agile sustainability. Comparative Agile Sustainability is an approach that we created in a small team with the support of data analysts that serves to anchor and promote the awareness of sustainability in an (agile) team and/or company. The evaluation was published under creative commons and is therefore freely available to all interested parties. By using the results of this validated assessment, agile teams and organizations can better understand how they can increase their own effectiveness and contribute to increasing sustainability across the industry.

If you’ve always hated Maths but love programming, this session is aimed at you. We will stay well away from anything remotely useful, and write code that helps us understand Sets (collections of things), Groups (for people who find adding up too complicated) and Graphs (dots with lines connecting them). These things are fun, honest. If you’ve always hated Maths but love programming, this session is aimed at you. We will stay well away from anything remotely useful, and explore some cool ideas by writing code.

Sets are collections of things, Groups are for people who find adding up too complicated, and Graphs are dots with lines connecting them.

Crucially, all of these are fun*, and we will play around writing some code that helps us understand how they really work.

*Note: apart from Sets, those are not fun, sorry.

We like to write code but—despite our best efforts—we make mistakes. Our program will contain bugs. Sometimes, we don’t write what we mean to write, sometimes we don’t understand an aspect of our programming language and at other times we lack—or fail to consider—some critical information about our program’s system environment. As a result, our program will not behave correctly. What do we do now? In this talk, I would like to take you through the entire debugging process, starting with a program that crashes. What do we do next? Which questions do we have to ask? What information do we need? What can we do to find the cause of the crash? Which tools can help us in this quest, and, last but not least, what can we do to make sure this bug never happens again? Thanks to real-world examples that we have encountered—and debugged—at think-cell over the years, you will learn how to reproduce, locate, understand and fix even the most difficult bugs.

What’s trivial about trivial types ? What can we say about the layout of the standard layout types? What is the lifetime of an implicit-lifetime type ? How are all these types different from aggregate types, literal types, and structural types? Why do we need them, and when do we care ? Everything you wanted to know about C user type categories and more. Modern C offers several new classification of user defined types that are in certain contexts treated like built-in types. Getting familiar with them will allow you to take advantage of the special provisions the language gives you and write better code. Knowing the boundaries of those specific situations will prevent you from falling into the UB abyss. Join me as we take a tour of language recognised user types, noting their advantages and pitfalls.

What are the practices that enable a team to reach Continuous Integration? Adopting each and every practice enables the fast flow of work, increased feedback, increased stability and higher throughput. Continuous Integration is by itself already a practice. It is one of the most critical to adopt to enable the fast flow of work through the value stream.

However, many teams believe Continuous Integration is just a tooling problem, to then say they practice Continuous Integration. Though they often do not and hence miss out on the benefits that come along with it.

This session goes deeper into the practices that each on their own enables Continuous Integration. Learn how to gain fast feedback, increased stability and higher throughput!

Refactoring is a word on every developer’s lips, but not always at their fingertips. Through the Gilded Rose kata, we’ll explore the habits and choices that move us towards (or away from) solutions that match their problem.

We will also see we can reduce much of the pain and churn of software development by viewing it through the lens of refactoring-driven development. Refactoring is not just tidying; it is a design practice and a discovery process. Refactoring is a word on every developer’s lips, but not always at their fingertips. There is more to refactoring than IDE shortcuts and code tidying. Refactoring is a tool for understanding and improving code by changing it and for revealing and implementing design choices. It is about uncovering possibilities, such as the paradigm that best fits the problem and new ways of thinking about solutions.

Many developers understand refactoring at a more superficial level and often do little more than rename identifiers or extract functions. This session looks to go deeper and to present refactoring as a first-class design practice.

We’ll walk through the classic Gilded Rose refactoring kata — don’t worry if you don’t know it, all will be introduced! — taking it from its initial painfully realistic business logic all the way through a series small changes to a solution that better fits the problem as described and simplifies future changes. We’ll look at what kinds of tests are suitable for the code, we’ll question some common coding habits, we’ll see that neither force-fitting an object-oriented approach nor tackling it just through procedural refactoring gives a good fit solution, and we’ll arrive at a solution that owes more to declarative thinking than imperative.

We will also see we can reduce much of the pain and churn of software development by viewing it through the lens of refactoring-driven development.

As with other complex software systems, test-driven development (TDD) practices offer benefits for development of embedded and system-level software. Unit testing enables a production of verified code independently from a target platform. Test-aware design supplemented with automated verification facilities significantly reduces testing time compared with manual deployment and quality assurance. Unfortunately, dependency on hardware and low-level APIs, platform limitations and portability issues can offer challenges for applying TDD techniques in practice. The presentation focuses on various approaches enabling testability of embedded and system-level code and covers such topics as TDD process, design for testability, techniques for decoupling from hardware and procedural APIs, organization of integration tests for embedded systems. The test-driven development (TDD) process is a widely used practice that can significantly improve product quality and strengthen developers’ productivity. Unfortunately, in the areas of embedded and system-level development TDD applicability faces some extra challenges. Dependencies on hardware and/or C-based system APIs, portability issues and platform limitations require more sophisticated test designs. The presentation is aimed at encouraging and enabling software engineers involved in the aforementioned fields to apply TDD principles in practices and consists of two consecutive parts. In the first part the TDD process will be reviewed through examples, covering how requirements can be refined using TDD and translated into unit and integration test-cases. The second, primary, part will be focused on design principles that enable testability and anti-patterns inhibiting it. Strong focus will be given to unit testing, the technique that allows not only to verify the correctness of code but significantly bolster developer’s productivity by providing a target independent environment. Cases where decomposition and abstractions can be used to produce testable, and platform independent units will be demonstrated. Special attention will be given to dependency injection as a foundation for platform abstraction and mock testing. C language features, facilitating dependency injection, such as compile-time/run-time polymorphism and callbacks will be analyzed from applicability, usability and performance perspective. Techniques for mocking procedural APIs, enabling testability of system API-dependent code will be discussed. Apart from unit testing, methods and practices that can be used to organize and orchestrate automated integration tests for embedded and platform dependent code will be reviewed. Although centered around application of TDD for embedded and system-level development with C language, concepts and techniques covered in the presentation are relevant for a wider range of software engineering fields.

Some people question the place of talks about human skills at a conference. I have news for them: software is built to run on computers by teams of humans. We know a lot about the machines we work with. Don’t you think it would be good to understand more about how humans tick, too?

"Modules will solve everything", people say — some optimistically, others sarcastically. However, modules are far from reaching real-world maturity, and it is still not certain whether they will improve compilation times in every situation and how costly it will be to migrate a large codebase.

Do we have to suffer with excruciating compilation times until we are able to migrate to modules? Not at all!

If you are interested in learning about practical tools and techniques to improve compilation times on codebases of any size, today, this talk is for you! We will cover: <ul> <li>How to accurately benchmark the compilation time of a codebase and detect bottlenecks;</li> <li>Enabling precompiled headers in CMake, leveraging the "reuse from" feature;</li> <li>Automatically transforming your build into a "unity build";</li> <li>When to selectively replace heavyweight standard library headers;</li> <li>General techniques to reduce physical dependencies between components.</li> </ul>

The rise of micro-service architectures offers the promise of a more agile software development process. Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organisations.

But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith? Contract testing with Pact offers an excellent solution. The rise of micro-service architectures holds the promise of a more agile software development process. Software systems will be made up of many collaborating components which are developed, deployed and operated by distributed teams and organisations. But how can we avoid a recurring configuration nightmare (c.f. DLL hell) and ensure that we benefit from the promised flexibility, rather than creating a fragile, distributed monolith?

One approach is suggested by the test automation pyramid, which suggests that we favour unit and integration tests over end-to-end tests, which leads developers to use test doubles (fakes, stubs, mocks etc.). The risk is that the developer’s test double does not behave in exactly the same way as the actual component that it is replacing. When this happens, the tests all pass in your build pipeline, but you get failures when it’s released into an integration (or production) environment.

Contract testing is a technique that can give you confidence that your test doubles are accurately simulating the dependencies that they replace. This is not a new technique, but the extra investment in creating and maintaining (yet another) suite of tests has restricted its uptake. Instead, organizations mitigate the risks by investing in more and more integration environments and end-to-end tests. This was always expensive, but with the adoption of micro-service architectures across the industry, the cost and complexity has escalated to a point where this approach is no longer sustainable.

Concurrency: safe, efficient, structured and easy to use — pick four. This talk aims at looking at the advantages and disadvantages of various concurrency approaches, trying to make sense of them, and trying to paint a picture of the solution space for concurrency. It goes on to present a concurrency model that fixes most of the problems found in the existing approaches. Concurrency is hard. It’s been hard since its inception, more than half a century ago. There are multiple approaches to concurrency, each with its advantages and disadvantages. This leaves programmers confused.

This talk aims at clarifying part of this confusion by looking at different approaches used in the past to tackle concurrency, providing a simple framework to analyse the advantages and disadvantages of these approaches. Moreover, by looking at past approaches and seeing the downsides that each approach has, we can infer a picture of how the future of concurrency might look like.

We dedicate a part of the talk to a concurrency model that is safe, efficient, structured, and very easy to use (with an emphasis on the usage). This model can be an important part of the future of concurrency.

A look into generics and some of the other languages features now available in Go, with live coding and live bugs, because who doesn’t love trying to code up audience questions on the fly. Go was designed to be simple, and easy to understand. Its use of interfaces and composable types meant it didn’t <b>need</b> generics. So obviously it now has generics. Which is great. Sort of.

Join me as I fire up an IDE and demonstrate the highs and lows of generics, and a few other new languages features we’ve gained in Go recently.

Before C20 we had to write 6 comparison operators for our user defined types (or even more). For sure, a tedious task. All this gets simplified with the introduction of the spaceship operator. What happens to your code, when you turn on “-std=c20” even before we go near the spaceship operator, did your build break? Why does that happen? We will first investigate, another new feature of C++20, the rewriting rules, and how that impacts your code base. And then we will dissect the spaceship operator, from a using perspective, and from an implementation perspective. Oh yes, comparison categories, what are those, and why are these important with respect to the spaceship operator? All will be answered, what initially looked so simple, does require some extra thoughts it seems to correctly use the tool.

Being introduced to C20, ranges changed the way we write code. C23 not only brings with it a large pile of new utilities but actually introduces a fundamental change to one of the core concepts in the ranges world - the view.

Absurd as it sounds, views can now also own their elements while still being cheap to pass around. This talk will explain how that works as well as describe the most useful algorithms and adaptors we can now take advantage of, like using std::generator to implement range adaptors, printing ranges, or even using the new std::optional monadic interface.

During the Second World War, Alan Turing and his team at Bletchley Park used a very primitive computer to crack the German Enigma machine encryption and allow the Allies to read the Axis secret communications. To achieve this feat they used every trick in the book to reduce the problem to something that could be achieved by an early 1940s electro-mechanical computer. What if we were nowhere as smart, but got readily access to a 16 cores 2020s CPU and modern C? In this talk, we will show a brief history of Enigma's design and cryptoanalysis at the time, and then will try to see if we can break it using a modern machine and some C20. How many combinations can we try per second using all our cores and with the help of some micro-benchmarking?

Working with others is tricky. Especially in the new world of remote work, having different workflows, habits, and backgrounds can cause friction in teams. But the "A-ha!" moments where someone else quickly fixes that bug you’ve been stuck on for three days make it all worth it. In these working sessions, the first obstacle is finding a way you can share your codebase and progress quickly – without having to resort to individual screenshots and complicated workarounds. In this talk, we’ll introduce several collaboration problems faced by distributed teams and discuss tools and solutions you can use in your development process today, including sharing at anytime and anywhere with Live Share, sharing the same codebase across different IDEs using CMake Presets, sharing in the same cloud instance of an IDE, and more.

Debugging tools (debuggers, checkers, tracers, time-travel debuggers) all rely on debug info to map from the executable back to the source-code. This talk covers what exactly is in debug info, the different compiler options to control its generation, and the different kind of object files and why you might want them (e.g. split dwarf files for quicker loading). We also introduce ways to manage this information, including the new debuginfod service. Many different Linux debugging tools are available - as well as the traditional debuggers (GDB, LLDB) we have checkers (Valgrind, the sanitizers), tracing tools (strace, ltrace), time-travel debuggers (rr, UDB). They all rely on debug info to map from the executable back to the source-code. Most of us know to pass the -g option to gcc to generate debuggable binaries, but there is much more to it than that.

This talk covers what exactly is in debug info, the different compiler options to control its generation, and the different kind of object files and why you might want them (e.g. split dwarf files for quicker loading). We also introduce ways to manage this information, including the new debuginfod service.

As is usual for Greg’s talks: few slides, many demos.

This talk will give the information you need in order to use the available tooling more effectively, and to troubleshoot when the debug experience doesn’t quite "just work".

Andy teaches CB about neat features of Rust and CB tries to show that they have what they need in C++. Andy has been working in Rust and is excited to share his experience of all the positive features that he has found useful.

CB has decades of experience with C and years of experience in other languages and is sceptical of the need to invest time in another language. They have reluctantly agreed to "hear Andy out" and are confident that they have everything which they need in C to tackle the same sort of problems that these Rust features are supposed to help with.

Andy is looking forward to demonstrating <i>ownership</i>, the type system, immutability, pattern matching, safe concurrency, helpful compiler messages and, worryingly for CB, the package ecosystem.

The landscape of software development is constantly evolving, and thus the languages and tools we use must evolve.

In recent years, a number of new programming languages and compiler projects (Rust, Circle, Carbon, cpp2, Val, etc) have been started with the goal of improving software development which would typically be done in C with traditional compilers. Additionally, the C language has begun considering new and bold evolutionary paths to respond to the changing needs of the community.

Come to this panel for a lively discussion of the merits and future of C++ and these next-generation projects.

This talk is about using the latest developments in C for really small systems. Since C11, Standard C++ already provides some mechanisms to run task on multpile cores. RP2040, the processor of Raspberry Pi Pico, features two Cortex M0+ cores, but as an implementation of the Armv6-M architecture it’s not really meant for symmetric multi-processing (SMP), so std::thread is not appropriate for using these two cores.

But with coroutines in C20 and std::execution (probably in C26) there are other standard mechanisms in C++ to utilize multiple cores.

COS is a proof of concept that implements the C Standard API as pre-emptive multitasking system on bare metal. This makes it possible to explore how far the C++ Standard interfaces can provide the interface for portable embedded applications and what’s still missing.

COS also provides a partial preliminary implementation for the std::execution interface that's currently proposed for C26. This allows for more task launching control than simply std::thread.

This presentation will not go deeply into the technical details of RP2040, but will show several applications that use both cores based on the the existing and proposed mechanisms of Standard C++.

Electronic trading, in particular for high-frequency and low-latency strategies, is an area that is very much in demand of C developers, but sometimes seen as alien by traditional technologists. In this talk, we'll attempt to demystify this industry, present the problems people try to solve in it, and explain which parts of C has made it such a prevalent tool there. The talk will be primarily focused on electronic trading on centralized exchanges with continuous matching of limit orders, be it for delta-one or derived assets, on co-located or cloud exchanges. We’ll first cover the basics with reference and market data, execution, and order book kinematics, then discuss how one would build a program with low-latency trading capabilities as a result, with optimized thread models, networking and memory management. Finally we’ll delve into a few more quantitative topics to understand how it all fits together: matching engine simulation, alpha modeling, slippage and risk management.

If you are a seasoned C programmer you might think about C as a prehistoric language stuck in the times of K&R. But have you ever heard about compound literals and about how they can be used to enable default function arguments in C? Or have you ever used flexible array members to simplify dynamic data structures creation? What about anonymous unions, designated initialisers or static array arguments? Never heard of those? C is a living language that has much to offer to those who care about performance, who program close to hardware or whose daily routine involves interfacing C with C code. If you are such a person, or you are just curious and would like to learn about the older, little brother of C++, this is a talk for you. We will (re-)discover the perks and perils of modern C. Step by step, we’ll see how leveraging the latest language features helps readability, improves safety and leads to better runtime performance. Who knows, maybe you’ll find writing C enjoyable (again)?

In the next decade, three major new C will reshape how we write C code - reflection, pattern matching, and senders. Come join Bryce Adelstein Lelbach, one of the leaders of the C committee, to find out what's next for C, and why you should be excited about it.

I’ll show a worked example with a "before" and "after" using C coroutines. C 20 introduces coroutines into the language. Coroutines have the potential to greatly simplify some types of code - particularly, but not limited to, anything asynchronous in nature. But early adoption has been hindered by both the lack of library support in the standard and the inherent complexity of the feature itself (which, due to that lack of library support, you are typically more exposed to).

Now we have a bit of a “Blind men and an elephant” problem - where we’re getting disjointed glimpses of what coroutines, supposedly, are - without the big picture. I can’t claim to be able to give you a comprehensively big enough picture in a 90 minute talk, but my aim is to plot a journey through it by starting with a motivating example (a typical multiple async task problem), looking at how we might approach this without coroutines, then seeing what coroutines can do for us - and finally looking at what that might look like with library support, too.

After years indulging in the temptations of micro-optimisations, I shall present a definitive, micro-optimiser’s guide to implementing template meta-state machines! This was motivated by the cut-throat arena of High-Frequency Trading (HFT) and my own experiments. Extensive effort has been made to see just how far one can get using extensive template meta-programming to optimise the performance. Following on from my previous talks regarding optimisations in C++, I undertook a multi-year investigation into extreme micro-optimisation of template meta-state machines. This Herculean effort eventually hit a "hard limit": due to Shannon’s Information Theory…​ The meta-state machine described was a cut-down variant of the renown Boost.MetaStateMachine (mine lacks guards and other such flexilty). Each transition has been instantiated in a custom-container I termed "unordered_tuple", it provides extremely fast run-time access to each element. The input state has been encoded, using template meta-programming, in the enum tag-value to try to ensure that fastest possible instruction-encoding. The hashing of the state to identify the correct transition in the table uses a custom-designed, data-parallel algorithm that attempts to generate via brute-force an extremely fast, perfect (possibly minimal) hash: this might fail due to inadequate entropy. All this to generate a …​ computed goto! (Forgive me Dijkstra…​) So having erased all type information via the generated computed goto, type-safety was restored via some futher template meta-programming: the "constrained_override_type" that generates a specified override-set of functions and suitable abstract base-class. An analysis of the generated assembler that should demonstrate the efficacy of the techniques shall be given, followed by a performance comparison versus the much more simple "if-else" chain one may have used to implement the lookup of the transition in the meta state-machine.

Ever wonder how your computer went from ones and zeroes to full-color photos, streaming movies and high-paced 3D entertainment? Let’s take a deep dive into how file formats work, how to read files and what makes a file format a good file format.

How to jointly compute on private data, without revealing the inputs, but still getting the outputs Sometimes multiple parties need to execute a computation where each of the parties holds one of the inputs that they can’t or don’t want to share with the other parties. A non-technical solution would be to find an external party trusted by all the data holders and have that external party run the computation and announce the results.

But sometimes such a mutually trusted party does not exist. Then a technical solution is to run the computation jointly in such a way that everyone involved learns the result, but nobody learns the inputs of the other parties. In this session we look at some of the protocols and techniques invented for this purpose. Perhaps unexpectedly for these results, high-school level algebra is sufficient for majority of the presentation.

Paradox grand strategy games are all about simulating history through various lenses (politics, economy, warfare, diplomacy, demographics…​) in real time. Over the last 20 years, our games have become more complex and more demanding on CPU computations. In this talk we will see how the threading model of the game simulation evolved over time to try and deliver the necessary throughput and latency required to keep the games fluid with more and more complex systems. We will focus on 3 models, the "old" which is shared by some long running production games such as Europa Universalis IV, Hearts of Iron IV and Stellaris, the "current" model brought by Crusader Kings 3 and finally discuss some thoughts and ideas of what future games may experiment with.

Monads are a common technique in functional programming languages to reduce boilerplate, abstract detail in order to produce simple, pure pipelines. While traditionally associated with languages like Haskell, monads are making their way into more mainstream languages, including C -- with monadic operations being added in C23. In time, these functional techniques may become core pillars of C++ development.

To many developers, monads are either unknown or confusing — they have a reputation as being notoriously difficult to understand. This talk, which will combine both theory and coding examples, aims to demystify the monad and enable attendees to gain insight into its internal workings.

While the focus of our talk will be on C, the ideas are relevant to any other programming language -- the shift towards these functional features is not unique to C.

No functional programming knowledge required. This talk will serve as an introduction to the monad design pattern. We will start by introducing functors (a related pattern) and use it as a building block to introduce monads. Throughout the presentation, we will show examples of how monadic operations can help turn our imperative-style code into succinct functional pipelines, while removing boilerplate, error-prone control flow, and side effects. The examples will relate to recent and upcoming developments for std::vector and std::optional in the C standard. Finally, the talk will incorporate a walk-through of the available monadic support in C, and we will discuss where C++ stands in comparison to other languages.

<p>Over the years, CMake has become the de facto standard build tool for C, and sooner or later almost all C developers have to deal with it in one way or another. For many developers it will stop at entering the right CMake commands to kick off a build, and, maybe, occasionally add a new source file to the build. But somebody has to set up that build in the first place. This talk is directed at those (soon to be) experts. In a case study I will show some ideas and tricks to use a library and tools for which there is no support in CMake yet.</p> <p>In the case study, we will look at a C-application that uses embedded SQL to talk to an Oracle SQL-database. To build the application, it needs to link against Oracle’s client library and the files with embedded SQL need to be converted to pure C before they can be compiled. How can we find that library when there is no CMake module for it yet? (We write our own!) How can we execute Oracle’s preprocessor to convert files with embedded SQL in a structured way when there are tens, or hundreds, of those files, possibly spread over different CMake targets? Come to my talk and I will tell you.</p>

<p>This talk considers why support for trivial relocatability would be a valuable addition to the C++ standard. Along the way, we also compare the various proposals that have been submitted to WG21 over the last eight years to achieve this.</p> <p>A known performance issue for containers holding non-trivial types, such as <span style='font-family:"Courier New";'>std::vector<MyClass></span>, has been the focus of ongoing discussion for almost a decade. When such a container needs to increase its capacity, the <span style='font-family:"Courier New";'>MyClass</span> objects need to be moved to a new location in memory. For simple types that are trivially copyable, that relocation can be performed quickly and efficiently by simply copying bytes and deallocating the original storage. For more complex types that are not trivially copyable, the container needs to loop over each existing object, moving each into the new location and destroying the old one. Numerous other types (such as <span style='font-family:"Courier New";'>std::string</span>, <span style='font-family:"Courier New";'>std::unique_ptr</span>, and <span style='font-family:"Courier New";'>std::list</span> in some implementations), though not trivially copyable, could be relocated appropriately and efficiently with a simple <span style='font-family:"Courier New";'>memmove</span> if such relocation were legal.</p> <p>In this talk, we will first look at the efficiency aspects of relocation in more detail. We will then briefly compare and contrast the various — and thus far — unsuccessful attempts to introduce something akin to trivial relocatability into the standard, including:</p> <ul style="list-style-type: disc;"> <li>N4034, “Destructive Move,” from Pablo Halpern in 2014</li> <li>P0023, “Relocator: Efficiently moving objects,” from Denis Bider in 2016</li> <li>P1029, “SG14 <span style='font-family:"Courier New";'></span>,” from Niall Douglas in 2018</li> <li>P1144, “Object relocation in terms of move plus destroy,” from Arthur O'Dwyer in 2018</li> </ul> <p>Library implementers have attempted to provide such a facility themselves, and we will contrast some of these approaches, including Facebook's open source Folly library and Bloomberg's open source BDE library.</p>

Memory reclamation in concurrent programs is difficult. Hazard pointers, which for C++ are currently progressing through the Standard Committee, are a scalable technique for solving the reclamation problem. Another library-level approach is epoch-based algorithms, which offer very different run-time characteristics. This talk provides an introduction to the epoch-based approach, some qualitative comparisons to hazard pointers, and suggestions for further reading. In single-thread applications, memory reclamation (making memory available for reuse) after logical deletion is always safe. In concurrent programs, memory must not be reused while other threads might still access the memory. For example, consider deleting the first node in a singly-linked list. While the node may be removed from the list immediately (ignoring ABA), other threads may still attempt to access the node. Until these attempts complete, the node’s memory must not be reused.

In its simplest form, an epoch-based reclamation algorithm tracks how many threads have access to a data structure’s nodes. This count is maintained in an active epoch and one or more waiting-until-empty epochs. Each epoch has an associated list of logically deleted nodes. A thread, prior to accessing any nodes, increments the active epoch count. When the thread completes accessing nodes, the thread decrements the count it previously incremented (not necessarily the active epoch count). Memory logically deleted is always added to the list associated with the active epoch. Periodically, a new active epoch is started and the current one, along with its associated list of logically deleted nodes, is now considered a waiting-until-empty epoch. When the number of threads in a waiting-until-empty epoch goes to zero, the associated logically deleted nodes are reclaimed.

A key theoretical issue with epoch-based reclamation is that an unbounded amount of memory may be held for reclamation. A potential benefit is performance. These and other characteristics are qualitatively explored, with references to prior work.

Modified condition/decision coverage is an interesting and arguably underused coverage metric. While important for safety-critical software (being mandated by several safety standards), it is not very popular outside of industries like the automotive and aviation, and the lack of support in the large compiler suites makes for a high barrier of entry. This talk is an introduction to MC/DC and presents the why and the how to get started with this useful metric.

Don’t look in the box! Forget about Monads and burritos - let’s get practical and see how C++ got more functional by way of Rust Option(T) and Haskell Maybe. Can we write cleaner code using continuations? Let’s see how combinators (higher-order functions) can be used to manage control flow in a modular fashion.

This talk gives practical advice for learning and improving skills with modern C. The talk identifies five programming ‘mindsets’ that are key to C and describes how to develop each. By blending these mindsets together (and consciously recognising when to switch), programmers can continuously improve, which ultimately leads to one form of C++ ‘mastery’.

The talk begins by examining the imperative programming mindset, which includes the design of user-defined types. The talk then focuses on the mindsets which underlie C compile time programming, functional programming (with C), concurrency and performance. The differences between the various forms of thinking are distilled and practical guidance is given for how to cultivate each. The talk concludes by highlighting that there are many other mindsets which contribute to C mastery, for example, debugging, testing and optimisation. This talk is intended to highlight the fact that C (and programming in general) does not consist purely of a single mindset. Moreover, software engineering requires many different ways of thinking to be blended together to produce the best possible solutions. The aim of the talk is to identify those mindsets that are key to C++ and to provide practical guidance for developing each. The talk is suitable for everyone and all levels of ability.

Learn how Bloomberg leverages Behavior-Driven Development (BDD) and the ‘behave’ framework for end-to-end testing of cross-team distributed systems. Software clients don’t care (and shouldn’t need to care) about how code works. They only care about two things: 1) Does it work? and 2) Is it reliable?

As engineers, this dual expectation around stability and quality creates the need for an essential part of our software development process – testing. However, in large-scale distributed systems that span multiple teams across an organization, how do we ensure full end-to-end test coverage is captured?

One possible solution could be hiring a Quality Assurance (QA) team to manually test every client workflow. But manual testing is rarely sufficient and extremely time consuming. Generally, the low ratio of testers to developers can delay production deployment for new code, while also opening the door for more errors to be caught by end-users.

Building out reliable automated testing requires a tight partnership between engineers, assurance experts, and customer support, as well as the thorough translation of client workflows into a technical pipeline. For distributed systems that span multiple teams, it is also critical to have an automated triage process and clear ownership for each part of the pipeline.

This talk will illustrate how Bloomberg engineers have leveraged the ‘behave’ framework and behavior-driven development to enhance our testing framework.

A look at some of the places where C now offers multiple ways to do the same thing, examining some of the strengths and weaknesses of each approach. C has undergone many changes since the first ISO version was published in 1998.

Some of the features that have been added to the language provide a replacement for existing idioms.

In this talk I will look at some of the trade-offs involved in such replacements and examine some of the strengths and weaknesses of the different ways we have in the current language of achieving the same end.

The set of issues involved include: - readability and expression of intent - the likelihod and consequences of things going wrong - the cost of change

The talk will be based on features of C++, although many of the principles have a wider application.

Ever thought of doing a C application user interface in React (even using Typescript into the bargain)? I've been part of a team working on a large C audio application doing exactly that. This session is a report on how it’s been going, what has been good and what has been…​ less good. You have a large C codebase that uses JUCE, a multi-platform C framework widely used in the audio world.

JUCE includes C++ GUI classes, so you can write your GUI directly with JUCE. But that means a compile and link every time you need to adjust anything, which can be tedious with a large code base, and besides, JUCE’s GUI classes are pretty traditional. What if you could write your GUI in a more declarative fashion with React? And enjoy seeing changes in UI code show up immediately without a compile-link?

This the story of exactly this journey, using the open source react-juce library. We’ll learn a bit about JUCE, take a dive into how react-juce works (and so see how potentially you might produce a React backend targeting a different C++ GUI toolbox), look at how such a GUI might perform, and reflect on the lessons from the project.

This talk will discuss how socket concepts like select or poll can be used when composing all kinds of concurrent operations in C++. Unix systems implement a rich set of primitives for working concurrently with file descriptors. Interfaces like select, poll, epoll, and kqueue allow the caller to wait until an event occurs on any of the specified file descriptors - that is, until at least one of them becomes "ready" for some operation. The Go programming language has a "select" statement with similar semantics. It may be used to wait for any of several "channels" to become ready.

This talk will demonstrate to attendees that such an approach is also viable for solving problems that involve concurrent operations. It will also how C++ concurrency mechanisms could support similar semantics. By the end, it will provide answers to questions like: "How can I .get() the first of several futures?" and "How can I co_await the first of several coroutines?"

The Software Engineering Culture module at the University of Portsmouth follows the model of preparation for a conference. The first assessment is submission of a bio and a selection of proposals to our 'call for papers'. The students act as the programme committee to choose the proposals they want to see. The final assessment is a presentation of the selected talk by each student. In this session you will learn more about how we run the module, and help influence what material we choose for the class of 2024. You will also hear one of the student talks from among the highest scoring proposals. Software Engineering students take this module in the final year of their degree. They discover the profession and its practices through videos, articles and debate, preparing them to learn from other professionals, share their own knowledge and engage in informed debate.

We include the issues of inclusion & systemic inequality, and the burgeoning responsibility upon Software Engineers to recognise these problems in order to promote healthy work environments for all and design-out systemic inequality and exclusion.

These issues are among the topics whose evolution we examine in the history of the profession. We also look at the how practices and architecture have changed in order to help students learn from the past and look to the future of their careers.

With coroutines being readily available and supported in all mainstream compiler implementations, more use cases than simple generators and tasks are entirely within reach. As any operation which may use I/O or execute on a different context is effectively asynchronous, the question then becomes whether all of these should be co_awaited. Of course, the implication is that essentially everything which isn’t just a computation should then be co_awaited.

This presentation discusses some experiments of making things optionally asynchronous. It talks about the design choices encountered, some of the implementation details, and some performance results when making implementations optionally asynchronous.

The presentation is targeted at experienced C developers. Dietmar Kühl is a senior software developer at Bloomberg L.P. working on the data distribution environment used both internally and by enterprise installations at clients. Before joining Bloomberg he has done mainly consulting for software projects in the finance area. He is a regular attendee of the ANSI/ISO Cstandards committee, presents at conferences, and he used to be a moderator of the newsgroup comp.lang.c++.moderated. He frequently answers questions on Stackoverflow.

An experience report showing how remote mob programming can be quite effective in high stake environments, which include very short deadlines, high visibility (especially for failure), limited knowledge of some of the technologies to use, and some hard security and accessibility constraints. When you have a newly formed remote team, which has to deliver a system in a high stakes environment—characterised by very short deadlines, high visibility (especially for failure), limited knowledge of some of the technologies to use, and some hard security and accessibility constraints—remote mob programming might not be at the top of your list of methods to use. Yet, this is what we did to deliver successfully, and to very high-quality standards one of the backend systems used by the COVID-19 app for England, and Wales, UK. In this talk Giovanni will share some lessons learned (warts and all) on how remote mob programming helped them achieve their very challenging goals, learning a lot in the process.

A collection of design techniques for hardening library interfaces against misuse and catching common user errors at compile time. C is a language with many sharp edges. Besides the core language providing plenty of features that allow users to shoot themselves in the foot, higher-level library interfaces are also often designed with complex preconditions, the violation of which can again lead to undefined behavior and results that are just as unpredictable as what results from misuse of a lower level language feature. Fortunately, through clever use of the C type system we can design interfaces in a way that makes them much harder to misuse accidentally and drastically reduce the opportunities for bugs in user code.

In this talk, we will present a number of design techniques that allow library designers to reduce the possibilities of misuse by their users, by pushing the detection of precondition violations from run-time to compile-time. We will show how to distinguish different categories of preconditions and how we can use the C++ type system to prevent accidental violation of those preconditions at runt-time. We will demonstrate with a number of code samples how the use of such type-based techniques prevents interface misuse in practice and take a look at the trade-offs that arise from such an approach.

Have you ever wanted to take advantage of all the MIPS in your machine with one programming language? Have you ever wanted to support any kind of offload devices in C, be they FPGA, GPUs, matrix/tensors, or DSPs? Many people have by augmenting a SYCL compiler. Have you wondered why US National Labs are choosing SYCL as a standard programming model for exascale computing? This is because they know maximum performance can be achieved with a combination of host and accelerator devices in any vendor combination, so they choose SYCL. Khronos SYCL is a framework language built on top of Modern C. It is backed by an open standard in Khronos and enables ML frameworks and Standard C code on top of template libraries with lambda functions that have host and accelerate device code in a single source, but still enable separate compilation of host and device code. The device SYCL compiler may employ kernel fusion for better performance and the host CPU compiler can be any C compiler, from clang, GCC, VS C, or IBM XL compiler. Many people have built SYCL compiler additions to dispatch to any variety of devices very quickly, from students to academia, to industry. There are already a number of backends including CUDA, PTX, OpenMP, AMD, NEC, Huawei, Kokkos, Raja, and TBB in addition to OpenCL. There are also many interesting use cases with complex modern C. PyTorch, Blender, ray-tracing, Flashlight ML, Eigen and Tensorflow, Gromacs, and CERN’s ATLAS experiment for high energy physics.

This talk from members of the SYCL and C community will talk about highlighted features from the latest SYCL 2020 as related to ISO C. SYCL can serve even more Extreme Heterogeneity where Data Movement is still King. We also are entering the era of software and hardware Codesign with extreme Heterogeneity and SYCL can be a part of a standard programming model for all HPC, Embedded AI/ML, and Automotive

This talk will showcase these features and show how SYCL 2020 has increased expressiveness and simplicity for modern C++ heterogeneous programming.

This lecture presents how Modern C features enable exciting features and attractive new design possibilities. mp-units is a Modern C library that provides compile-time dimensional analysis and unit/quantity manipulation. It heavily uses C++20 features like concepts and values of class types used as non-type template parameters (NTTPs). Also, it introduced a new powerful technique called the Downcasting Facility.

During the talk, the library’s author will describe the significant challenges with the initial design. He will explain the issues with the Downcasting Facility and why user-defined literals (UDLs) are not a good choice for creating quantities, and what the alternatives are. Mateusz will also describe additional requirements that couldn’t be addressed with the previous framework and present how the new design addresses them. We will also see many C20 and some C23 features in action :-) In the end, we will discuss potential C++ language features that could be helpful to improve the design of this and similar libraries.

One common way to design concurrent code with less potential for synchronization and other concurrency errors is to use message passing. In this talk, I will walk through the design of some example code, showing how to build such a system in practice This talk will include a brief description of what message passing frameworks are, and how they can help avoid concurrency errors.

I will then work through some examples, showing how the tasks are divided between the elements, and how the system can therefore utilise concurrency, while insulating the application code from the details of synchronization.

<p> Designing a good function API is not an easy task, but many useful guidelines exist to facilitate this process. However, one aspect of a good API is often given insufficient attention: what to do when the function is called with arguments outside of its domain — i.e., when the function preconditions are violated. Artificially expanding the function domain — e.g., by throwing an exception or returning an error code — might be a tempting option to handle inputs that are syntactically but not semantically valid. Instead, we will show how using a contract-checking facility — even one as simple as C <code>assert</code> — to detect misuse leads to reducing the incidence of software defects and facilitates robust, maintainable, and high-performance software. </p>

<p> We will start by considering what constitutes a complete function contract; when and why narrow contracts (those with preconditions) are preferable to wide ones, and how to use defensive checks to detect the function’s misuse by its programmatic clients. We will then focus on the practical aspects of using function contracts in real-world software. We will touch on rendering function contracts for consumption by the function’s (human) clients, on the necessity and implementation of testing the contract checks themselves, and the design considerations for a contract-checking facility suitable for use at scale. </p>

Code isn’t just instructions to a computer. Code tells a story. What you write is an important as how you write it, and how you convey that story matters. What particular bug caused this line of code to be added? Why are we calculating things that way? What was the context of a particular design decision? All of this information comprises the story of the code. And yet, a lot of the time we just throw it away. We view the code as all the documentation we need. There is so much more to this story, much of it that may well be relevant to later decisions, changes and updates. So let’s not throw this all away. Lets look at the story the code tells, from Once Upon A Time to Happily Ever After.

The C community (especially professional developers) are increasingly looking for tools that can automate their development processes. Organizations spend significant amounts of time maintaining in-house tools, scripts, and other assets designed to keep their developers productive. This talk addresses one area impacted by this: managing C dependencies. There are lots of package managers on the market, and several have been gaining popularity in recent years. If you are interested in learning what modern package managers can do for you, and which package managers to use in different situations, this talk is for you. According to recent surveys from the Standard C Foundation, a majority of C developers are manually managing their library dependencies. Curiously, one of the top pain points cited in these surveys was also “managing libraries”. I believe these two points are correlated.

In this talk, I will discuss how different types of package managers address these pain points, from system package managers like apt and Homebrew to build system centric package managers like NuGet and language package managers like vcpkg and Conan. There are pros and cons to every solution, and some package managers are more effective in some workflows than others. Managing libraries doesn’t have to be painful. If you configure your workflow right, you will save time not having to maintain additional git submodules, source code, or reading build instructions on GitHub.

I’ll also talk about a few scenarios related to dependency management: acquiring open-source libraries vs. private libraries, automatically building libraries from source, using libraries locally and in CI, using libraries with different build systems and operating systems, and acquiring developer tools from a package manager. You will come out of this talk with an understanding of how a package manager can rid you of your dependency woes.

Dive in the mind of a AAA game developer and learn the ins-and-outs of being a productive game developer. As blockbuster AAA video games increase in complexity, so has game development in C++. In this talk, we will take a deep dive inside the mind of an AAA Unreal Engine developer at RareUK. Using Unreal Engine 5, we will showcase key productivity tips and tricks throughout the developer inner loop when working with Unreal Engine. Learn about how to reduce mental task switching with various productivity features and Unreal Engine IDE integrations in Visual Studio. See how a game dev can leverage little-known advanced debugger tricks and a custom Natvis file to their advantage.

It is trivial to make a class callable in C. Just define <tt>operator()</tt>. But what if you cannot? <p>Adding <tt>operator()</tt> requires three things to check simultaneously: you're working on an object of a class type, you own the class type, and the action of "call" has an unambiguous meaning in the class. You may think a closure or a <tt>bind_front</tt> object will solve all problems. But, depending on which pieces are missing, such a solution can range from adequate to a code smell.</p> <p>The talk will begin with an old tale: Java -- a language with no <tt>operator()</tt> and was transitioning to adding lambda. Then, we will look into how Java, C♯, and Rust avoid all the restrictions of <tt>operator()</tt> by not adding <tt>operator()</tt> to the language. Finally, we'll introduce a small library change in C that achieves all the benefits we’ve seen and even more.</p>

If you play a game once in a while, you’ve levelled up in it. You’ve completed a quest, a mission, a level, or something. And you’ve been rewarded. Some of the mechanisms that are carefully coded into games are very similar to mechanisms that happen in our careers. In this talk I’ll use the language of games (quests, loot) to talk about advancing and succeeding as a developer, however you define success. Every game has a core mechanic: winning battles, solving puzzles, finding matches, or whatever. In the same way, being a software developer involves a lot of writing code. But our careers involve a lot of other activities, too. Sometimes it’s not clear what the value of a meeting is, why you should join a committee or working group in your company or outside it, how social media can have relevance for a developer, why conferences are worthwhile, and so on. It’s rare for people to spell out the benefits of any work activity explicitly. I will show some of those benefits using the concepts and language that are common across a variety of games today,

In a game, you have to make decisions on the fly as new information arises. You may have to communicate plans to other people, without authority to make them follow the plan, and you may have to choose a path without all the information you need to make the decision. Surely that sounds familiar to programmers? If you’ve figured out some meta-play that works for you in a game you like, you can do the same for your software development career.