ACCU 2021 Sessions

C++ is no longer C with classes and it never was only 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 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, EBO, CRTP, Type Erasure, 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. C++11/14 knowledge is suggested but not mandatory.

Environment: A laptop with a relatively new C++ compiler. It is recommended to have the latest version of one of the compilers (Visual Studio, gcc or clang).

This workshop is trying to simplify your use of C++. We have many great rule sets to chose from, some partially outdated, like Scott Meyers 3rd edition, some futuristic, like the C++ core guidelines. While working on the AUTOSAR C++ and new MISRA C++ guidelines I found that many of the guidelines forbid things without giving actual guideline on how to do things and when to deviate.

Also many talks on C++ explain the modern features and show how they work, but only few put things into context and show what to give up and how things combine sanely. I am guilty of that in the past as well, e.g., with my constexpr compile time computation talks at ACCU.

This full day workshop is the result of thinking about that. It won’t show C++20 feature by feature, but gives a coherent set of practices to improve your design and code using existing standard C++ features where they give you benefits.

We will cover the following topics:

If you are brave enough, bring your own examples that we can look at and discuss where they are perfect and where they could be improved. Otherwise, we will take a look at potential bugs in the C++ standard library design.

There are many ways to build and package your C++ code, each with a different approach to supporting multiple operating systems and toolchains. Integrating third-party components into your software often means having to deal with even more build systems. All of that without even mentioning topics like cross-compilation. How to grasp and handle all of this complexity? In this workshop, we would like to show you the modern tooling that takes a lot of burden out of build management. We’ll cover the state of the art utilities such as CMake, Conan, clang-format, Nix, pre-commit, and Docker. Because cross-platform development should be fun!

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 Gail 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.

A workshop based on the Better Code series of lectures with opportunities to experiment and discuss the ideas presented.

Writing code is challenging, especially writing efficient code on large projects. We’ll cover types, algorithms, data-structures, runtime polymorphism concurrency, and relationships. Each section provides insight into how to reason about your code and specific techniques to build better code.

The prerequisite for this course is a basic understanding of C++. Developers at all levels will learn some new ideas and techniques to improve their code quality, efficiency, and readability.

Requirements: Please come prepared to run a C++17 command-line application. [Links to a github repository with starter code will be provided in advance.]

Becoming agile as an organization is a journey. It takes time to change attitudes and behaviours. Especially for a larger organization, you need a multitude of coaches and change agents to succeed. My focus is specifically on coaching technical practices and how people write code. Over the years I’ve tried several approaches and this talk is about the best way I have found so far to promote agility amongst developers. I work daily with teams, ensemble programming in their production code. I also lead a short ‘learning hour’ practice session. The combination of these two kinds of activity tends to have a powerful effect on a team and the way they behave in their production code afterwards. In this talk I will explain more about the method, which I have named ‘Samman Technical Coaching’.

Dynamic polymorphism in C++ has historically meant virtual functions and inheritance. However, these form only one possible design for solving this problem, and they bring several implications on performance, ergonomics and flexibility.

Type erasure is another way to implement dynamic polymorphism, as demonstrated in several talks by Sean Parent and adopted in other languages, such as Rust’s trait objects. But implementing type erasing objects which provide ergonomic interfaces in C++ is cumbersome and error-prone, leading to a large family of types and libraries with subtly different semantics and lower adoption rates compared to inheritance.

This talk will present a possible future design for interface-based type erasure in C++ that marries the convenience of inheritance to the benefits which it otherwise lacks. It will introduce the code injection and metaclasses facilities which are proposed for inclusion in C++ along with a prototype implementation of the design based on the experimental metaclasses Clang fork.

The STL is sometimes seen as a strange and dangerous beast, especially in the game development industry. There is talk about performance concerns, strange behaviours, interminable compilations and weird decisions by a mysterious "committee". Is there any truth to it? Is it all a misconception?

I have been using the STL in a production videogame that is mostly CPU bound and in this talk we will unveil the truth behind the rumours. We will start by a discussion about the most common criticism against the STL and its idioms made by the gamedev community. Then we will see a few practical examples through STL containers, explaining where they can do the job, where they might be lacking and what alternatives can be used. Finally we will conclude with some ideas on how we can improve both the STL for game developers and also how to foster better discussion on the topic in the future.

At the end of this talk, attendees should have a solid understanding of why the STL is sometimes frowned upon, when it makes sense to look for alternatives to the standard and most importantly when it does not.

Ever seen a drawing trying to explain the architecture or the functionality of an IT system, and you couldn’t make any sense of it because it was drawn so badly? Do you feel that your drawings are OK, but could probably be improved substantially with a few tricks, but you don’t really know what they would be?

I’ve made a lot of drawings over the years. I’m pretty sure not all of them were a success in terms of understandability. But at some point in time, I started reflecting on how my drawings look, and since then, I’m getting comments that apparently, my drawings look good.

In this session, I would like to share some of the reflections I make when I see somebody else’s drawing, show you some obviously bad drawings and discuss what’s wrong with them, and some of the tricks I use to create better drawings. The goal should be that when you leave this session, you’ve practiced a bit on how you can make your drawing look better, such that the reader or the viewer will understand it better.

In this session Andy and CB explore what linkers actually get up to when they pull together your C++ code and libraries to produce an executable.

This session is aimed at developers who have some experience with working with a compiled language such as C or C++ and want to know more about the how the last tool in their toolchain works.

The session will examine what information object files typically contain and what is required to make a complete executable program out of one or more object files. All of the examples and demonstrations will be using Linux and ELF object files, but the concepts are applicable across most modern environments.

We’ll define concepts such as sections, symbols, relocations and look at how code and data are managed in a program. We’ll explore how the operating system runs a program and how this shapes what the linker actually does. We’ll also explore aspects particular to C++ such as how template instantiations and inline functions are managed.

On the way we’ll look at tools that can be used for examining object files and executables that let us dispel the mysteries of the linker.

C++ is a language of choice for implementing software for safety critical or modern embedded systems, however, since its inheritance of many C features and low-level and performance focus it allows for problematic code that still compiles. Not only the risk of incorporating undefined behaviour and non-portability of implementation-defined behaviour can cause safety risks, but also developers misunderstanding the underlying rules of the language. Limiting C++ to a safer core language is the goal of many guidelines in this talk we show rules of a safer subset of C++ for the automotive industry by MISRA-C++:202x. Expect well-known stuff and surprising aspects to be addressed by such rules and what you will get as warnings from the corresponding static analysis tools. However, we will also look at safer C++ design beyond MISRA-C++ rules, because such design issues usually cannot be checked by analysis tools, for example, the use of strong typing and mechanisms that ease following some of the rules, such as the use of sized integeger types.

Rvalue references have been with us since C++11. They have originally been introduced to make moving objects more efficient: the object an rvalue reference references is assumed to go out of scope soon and thus may have its resources scavenged without harm. The C++ standard library, for example std::cref or std::ranges, makes use of yet another aspect of rvalue references: since they go out of scope soon, it is assumed unsafe to hold on to them beyond the scope of the current function, while lvalue references are considered safe. We, too, found this assumption to be very useful for smart memory management, in particular in generic code. Unfortunately, the C++ language itself violates this assumption in at least two places. First, rvalues bind to const&. This means that innocent-looking functions taking a parameter by const& and passing it through in some way silently convert rvalues to lvalue references, hiding any lifetime limitation of the rvalues. std::min/max are two such examples. Worse still, every accessor member function returning a const& to a member suffers from this problem. Second, temporary lifetime extension is meant to make binding a temporary to a reference safe by extending the lifetime of the temporary. But this only works as long as the temporary is still a prvalue. If the temporary has been passed through a function, even it has been correctly passed through by rvalue reference, lifetime extension will no longer be invoked and we get a dangling reference. These problems are not merely theoretical. We have had hard-to-find memory corruption in our code because of these problems. In this talk, I will describe the problems in detail, present our library-only approach to mitigate the problems, and finally, make an impossible-to-ever-get-into-the-standard proposal of how to put things right.

Use of proper types is crucial for both performance and correctness. The talk would cover bugs related to type correctness as well as code that may work but hide severe performance issues due to implicit casting, creation of unnecessary temporaries or just simple bad coding. We will walk through abruptly sliced objects, surprisingly dandling pointers, silent temporaries, undefined behavior and more. The typical type typos presented in this talk are quite common, you may find yourself browsing your code right after this session looking for them and meeting them face to face in your code.

The talk assumes prior knowledge of rvalue reference and smart pointers.

How technical debt can kill your business. How F1 teams crack technical debt. Abstract: Formula One is a multibillion-dollar business, an entertainment, and the pinnacle of the motorsport competition. F1 teams face incredible pressure to deliver. Nonetheless, at every race they manage to deliver and improve at the same time, cracking the technical debt and pursuing technical excellence.

Whereas many organisations instead struggle to find the time to do the same under the pressure of their delivery commitments.

This session presents 4 real-life scenarios and for each one, an epic-fail story detrimental to the business and a success story from an F1 team, with lessons learned.

Modularity is a long known principle for creating maintainable, changeable and durable software. In contrast to other programming languages, C++ did not have its own module system and used header files to structure code. But this has changed with C++20 which introduced modules as one of its bigger new features.

In this talk I will discuss the theoretical side of modules and their advantages over header files (e.g. faster compile times, invisibility of macros, preprocessor directives and non-exported entities, fewer name collisions and more) but the main focus will be the practical usage of modules today.

I will demonstrate how modules can be used today with the three major compilers and how to restructure your projects using modules. Also the support of build systems for modules will be discussed.

Testing in C++ is not easy, it requires a lot of boilerplate code, macro usage and/or understanding of complicated testing frameworks. But it doesn’t have to be like that. C++20 will enable us to reinvent the way we write tests. If taking a glance into the future of testing in C++ peaks your interest this session is for you.

In this case study we will address the difficulty of testing with C++ by implementing a new, fully functional, macro-free testing framework [1] from scratch with modern C++20 features.

The main goal will be to leverage modern C++ in order to make the following snippet compile and run: 1. int main() { 2. "hello world"_test = [] { // Running "hello world"…​ 3. expect(12_i == fib(7)); // hello_world.cpp:3:FAILED [ 12 == 13 ] 4. }; // tests: 1 | 1 failed 5. } // asserts: 1 | 0 passed | 1 failed

The session will also focus on how to design modern testing facilities such as: * Sub/sections * Parameterized tests * Behaviour Driven Development (BDD)

At the end of this session the audience will have a better understanding of C++20 features such as: * New additions to lambdas * User Defined Literals (UDL) * Concepts * Source Location As well as how and where to apply them. Additionally, attendees will get familiar with a new, expressive way of testing with modern C++.

Let’s get ready to test all the things at ACCU 2020 and follow the Beyonce rule - "If you liked it then you should put a test on it".

[1]: https://github.com/boost-experimental/ut

Static reflection is a forthcoming feature in the C++ programming that promises powerful new features for compile-time introspection of user source code. This feature, supported by increasingly capable constexpr facilities, will potentially be the Next Big Thing for C++23. This talk will cover the core concepts of reflection and reification and discuss several methods of providing language support for those features, including the approach taken by current Reflection TS and alternative approaches that are currently being considered. The remainder of the talk will present examples of how reflection can be used to augment traditional generic programming techniques to develop even more general algorithms based on introspection of class properties.

How many times do people claim testing their code is difficult, if not impossible? Or have hundreds of tests, most of which fail on a regular basis? As data science becomes more prevalent, we often see few useful tests along with the code. Often the "science" relies on data, and the tests end up pulling in entire datasets, run for ages and only state "fail" when they get to the end. You could hit the code with a hammer until the tests pass, ignore the tests or change the asserts, but does that give you confidence to deploy your solution? Even when the code uses randomness, you can test this. We’ll investigate some typical problems in machine learning, data science and programming in general, suggesting varied approaches to testing in order to increase confidence that your code Does The Right Thing ™.

Lightning Talks

When you start something new, you soak up guidelines — rules that guide, lines to not cross — to find your way. You make progress by following the always do this and avoiding the never do that. With experience comes the realisation that there are exceptions to these rules. With expertise comes the realisation that these are not exceptions, but highly context-dependent rules. The always do this and never do that you’ve relied on give way to it depends. Former certainties dissolve into a sea of possibilities. Context and dependency on context are hard to see, but they are critical to thinking and to code.

The creation of software is an exercise in knowledge acquisition and retention, and there are limits to what we know and what we can know, and limits to what can be stated and tested, but seeing software as knowledge structure has important consequences. All too often, assumptions about code dependencies and execution, remain unstated and unexplored, hidden behind not-quite-right mental models and weak formalisms for reasoning. Ask any developer to draw up the dependencies in their current system and, after a few boxes and lines, they’ll likely run dry, having barely sketched the tip of the tip of the iceberg. Most dependencies are out of sight and out of mind. Mentions of technology and third-party code are vague (versions and vendors completely overlooked), risk implications are unacknowledged (from left-pad to Heartbleed), the roles of developers and organisations and the real world are considered a mildly inconvenient abstraction.

This is software development. This is water. This is dependency.

The ranges revolution is nearly upon us! C++20 will include concept-enabled, range-based versions of all the standard algorithms you know and love, as well as new “views” which can transform the way you write code. In this talk we’ll offer an overview of the ranges features currently in the C++20 draft, with examples of how you can use them to reduce verbosity, avoid bugs and improve the correctness of your code, and in some cases get better performance. We’ll also cover the currently-available ranges implementations that you can use today, without having to wait for the next version of the standard.

If you’ve heard the buzz around ranges and are wondering what they’ll bring and how they’ll benefit your code-base, then this is the talk for you.

Generic programming is a technique where functions and data structures are defined as general as possible. The goal is that they work with different data types and therefore are reusable. In C++ generic functions and data structures are typically realizes by using templates. Templates are a great tool for generic programming but they come with their own set of challenges. They can be hard to read/write and influence compile times negatively. And sometimes they are even too generic. C++20’s concepts can help with that but I want to show how you can be generic in your code without writing your own templates. To do that, we will explore some C++17 and C++20 features from the standard library, like std::span, std::variant and std::any. I will explain what they are, where they are useful and how to use them. I will also show some features you can find in other libraries, e.g. GSL.

For twelve years, think-cell had been a Windows-only software company and our codebase of approximately 700k lines of code had accumulated many unintentional platform dependencies. Six years ago, we decided to port our application to the Mac. This change has affected every part of our development process: the project organization, build system and the way we program in C++ today. The commonly used cross-platform libraries such as Qt and boost were good tools to build on, but by themselves were not enough. For many concepts, such as mutexes, semaphores or shared memory, they only offer a common interface to platform-specific objects with very different semantics and lifetimes. We wanted light-weight, platform-independent C++ abstractions with identical semantics for rendering, internationalization, file I/O, mouse event handling, RPC calls and error reporting. Developing these was challenging, firstly, because we had to define which semantics our application needed and, secondly, we had to implement them on each platform. This was not an easy process but I would argue it has improved the quality of our code very much. By now, we have moved on to the next challenge and have started to move some functionality to web applications. We wanted to reuse our existing code-base of course, and that meant writing web applications in expressive, type-safe C++. Definitely an advantage in our book! We have built our web applications using emscripten, but thanks to a student intern, we generate type-safe C++ bindings, beyond those provided by emscripten, from any typescript interface definition. In my talk, I will give you an overview of the C++ abstractions we have implemented, focusing on the cross-platform problem areas where common semantics were hard to define due to limitations of either one of the operating systems, and of course I will show you our tools that let us write web application in C++.

Test automation and BDD are related, but they are not the same. To get the most out of each of them, we need to understand the separate challenges that they address before getting engrossed in the tools that have been created to facilitate their adoption. And those challenges are rooted in the interactions between the different disciplines involved in software specification and delivery.

In this session we’ll explore what test automation and BDD are - and how they separately contribute to successful inter-disciplinary agile delivery. We’ll also spend some time describing how they’re different, and look at several typical examples of what can go wrong when BDD and test automation get confused.

When I started learning how Unicode works, I knew it would be useful, but I never expected it to be so much fun. In this talk I will try to share my excitement!

We will tour some of my favourite characters and use them to help us understand how various character sets and encodings work, covering Unicode in most detail, but also mentioning the Latin-n family, GB18030 and even EBCDIC.

By the end of this session you will have strong opinions about how UTF-16 ruined everything, how UTF-8 is beautiful nonetheless, and maybe you’ll even have a favourite Unicode character yourself. Personally I am a big fan of U+FE18.

Time Travel Debugging simplifies debugging by letting developers freely step backwards, as well as forwards, through a program’s execution.

In this practical lunch and learn session we’ll demonstrate benefits of Time Travel debugging and show how it delivers a radically simplified workflow for debugging, compared to traditional methods of debugging forwards.

Our Engineer will walk through how developers can simplify fixing bugs by:

Deterministically capturing and replaying a program’s behavior Time traveling backward (and forward) in the code execution to the origin of the failure Reducing the amount of repetitive guesswork and time consuming restarts and stops normally involved in debugging The demonstration will feature UDB, Time Travel Debugger and the open source debugger, RR.

Performance has always been the goal for C++ and that can frequently come in conflict with teachability. Since I was a student, twenty years ago, until today C++ has been a staple diet in universities across the globe. But “C++ as a first language”…​ really?

There is a lot of room for us to make C++ more teachable and improve the quality of C++ teaching in UNI, so long as we’re not talking about CS1. First, students have to get over the hurdle of being algorithmic thinkers and then we can give them a language that has these sharp edges.

Is this a lost cause? I think not. Modern C++ is simpler and safer and we have numerous opportunities to make it more teachable at the same time. "The king is dead, long live the king!"

Types are important as a tool for enforcing program correctness. In this session we would discuss types, specifically - Point.

There is no real logic in adding up two points (result is meaningless) - so we probably may not implement operator+ for Point…​ Unless we want to calculate an average location, then summing 2 points and dividing by two should be supported, preferably treating the result as a real Point only after the division by 2. We would discuss this problem and see how we can implement methods that return different types for (almost) the same operation and enforcing compile time type correctness.

Discussion would go through actual code and usage of cool C++ features such as if constexpr, advnaced template techniques and more.

Is your team struggling with unproductive meetings and workshops? Are you unsatisfied with how your team comes together to refine requirements and specify solutions? Have you heard about example mapping and want to know more?

Specifying and delivering software is a process of discovery. No team has ever delivered a valuable product without discovering many things during the development process, but many teams struggle to get good at discovery. Matt Wynne created a technique called example mapping that has helped thousands of teams around the world use examples to reach a shared understanding of the problems that need solved. As a consequence there are fewer misunderstandings, fewer disagreements, and a smoother flow of value delivery.

This session will teach you what example mapping is and why it works. Through a series of practical demonstrations, we will explore the essential actions needed to prepare for, facilitate, and derive value from example mapping. This knowledge will then make it simple for you and your teams to adopt example mapping successfully (using the many excellent online teaching resources available) and adapt it to your specific context.

Some people believe that freedom of choice is the best thing we can get. If you’ve built a few C++ projects in your lifetime you may have experienced the freedom of choice: Makefile, autotools, shell scripts, Waf, Bazel, Maven, QMake, CMake, …​! This buffet is much more than any single person can eat!

When building Songcorder, a vinyl-to-digital converter, I had to integrate libraries built with a combination of Makefiles, Waf, CMake, and Conan. And to make them work on Linux, Mac, and Windows. With a nice CI/CD pipeline. I came up with a fusion dish that neither looks or tastes very good. But at least it satisfies the hunger.

I’ll share with you some of my insights into the current landscape of build tools and what I learned on this journey.

There are many ways to build and package your C++ code, each with a different approach to supporting multiple operating systems and toolchains. Integrating third-party components into your software often means having to deal with even more build systems. All of that without even mentioning topics like cross-compilation. How to grasp and handle all of this complexity?

In this talk, you will be presented with a portable solution to building and packaging your code using CMake. You’ll discover how to easily create and use toolchains for different platforms. Lastly, you’ll learn how to package your code and easily leverage pre-built packages using Conan.

Everyone is writing tests for their code, right? Having tests is a good start, but unless you’re testing every single line of code, there’s still chances for "fun" times with bugs.

Having an incomplete set of tests can provide a false sense of security, but manually checking every possible execution path is tedious and error-prone.

Thankfully, there are tools which, when used in conjuction with our test suite, can highlight code that is never executed - the gaps in our test cases. Armed with this information, we can add to our existing test suites to cover these (hopefully edge) cases.

This talk will focus on the GNU Compiler Collection, but other compilers (such as Clang) also include similar tools. This talk is about the process, not the tools.

Tooling is an essential part of creating solid software: it helps us find errors, build what we want and understand what we’ve built. With a compiler that’s eager to help, accessible documentation and modern dependency management, Rust consistently scores highest in developer surveys when it comes to development tools. Working with Rust in 2020, I learned just how much its ecosystem lives up to this reputation, and wished I’d had a similar experience in C and C++ projects.

However, switching to Rust shouldn’t be the only way to have this aha moment. Instead, we can examine Rust’s tooling to learn how it manages to provide you with exactly the help you need - exactly when you need it, and apply this knowledge to the helpers we build for our own ecosystem.

This talk examines the culture, technical insights and resulting design decisions that shaped how the Rust community approaches tooling. We’ll be looking at core infrastructure like rustc and learn how their best practices organically influenced third-party efforts such as knurling-rs.

We’ll wak through what Rust’s friendly tooling looks like in practice, and which lessons learned from building it can be applied to improve development workflows in other languages too.

Humans tend to be competitive. With that in mind, it is perhaps not surprising that anything can be turned into sports, including intellectual activities like programming. This short presentation intends to give an overview of the world of competitive programming and also reflect a bit on its relationship to software engineering. If there is enough interest, we may follow up with a practice session after the hours!

With more and more systems moving into microservices architecture we often find ourselves designing new integration endpoints and scrutinizing message schemas. As we design new service API one thing can be said for certain – at some point it will need to change, preferably without breaking every service around it. And this is where backward compatibility matters. This talk is about schemas versioning and different options to consider when designing services – binary serialization or JSON? Shared schemas or schema-less? We will start by a brief overview of backward and forward compatibility and why both are important but tricky to achieve in practice. Next we will dive into details of JSON and binary serialization issues. For binary serialization we will use Apache Avro and Google Protobuf as examples and will look into implementation details of integer packing and usage of field IDs. Finally we will summarize how encoders drive compatibility and, eventually, services evolution.

Are you on the receiving end of a firehose of immutable structured data, which you want to analyse using SQL queries? Have you come across ClickHouse before?

ClickHouse is an open-source column-oriented database management system with SQL querying written in C++. For the past few years I’ve been using it at the heart of an analytics application handling 12 billion records of DNS transactions daily on a cluster of 4 servers.

This talk will give an introduction to ClickHouse and demonstrate what you can do with it and a large lump of data on a humble laptop.

A user shell is the way in which a user interacts with a computer system. It is the way in which input from keyboards, mice, touchscreens etc reach the system and applications and the way that output reaches the screen. A shell is responsible for launching applications, routing input to the focussed application and compositing the output from the visible applications onto the display.

Confinement is a way of restricting the capabilities of a program to specific devices, parts of the filesystem and other features of the system. An "unconfined" program can access anything that the user has permissions to do. So, for example, it could read any of the user’s files and copy them to the internet. The use of confinement is of increasing importance in computing as the basis for trust between the developer of a program and its user becomes increasingly tenuous.

Drawing from experience with adapting graphical shells and other applications to "confined" execution we examine what is needed to securely run untrusted applications on a computer.

PowerShell was unleashed on Windows developers and administrators back in 2006 in an effort to fill the long standing Windows CLI void. Fast forward 10 years and the shell-cum-scripting language can now also be found on macOS and Linux as part of Microsoft’s new found love for Open Source and cross-platform tooling.

Unlike traditional shells which traffic in lines of text, PowerShell leverages .Net Core and allows whole objects, generated by its own 'cmdlets', to be passed through pipelines alongside the simple lines of text generated by the vast catalogue of existing command line tools we all know and love. As a consequence this shell / scripting language hybridization means that administrators and developers can solve problems using whichever paradigm they are most comfortable with. Throw in support for remoting, modules, a package manager, the native .Net Core libraries, etc. and you have a mature ecosystem for writing everything from cryptic one-liners to full-blown applications.

If PowerShell has entered your conscious incompetence and you’re curious about what it might offer, this talk introduces you to the basic concepts and aims to give you enough of a grounding to help you explore further.

C++ cross-platform development is difficult. These difficulties are compounded by the fractured solution space, where every project seems to use a different combination of build systems, package managers, and diagnostic tools to address shared challenges. Join us for a discussion and demo of C++ cross-platform development centered on common pitfalls and widely adopted tooling. <br><br> Learn how to leverage CMake and its new CMakePresets.json to seamlessly build across operating systems and platforms. Untangle your dependencies with tools like vcpkg and Conan to avoid inconsistencies between system package managers. Debug your projects across multiple platforms with remote debugging. We’ll also explore how CMakePresets.json is supported on the CMake command line, in Visual Studio, and in Visual Studio Code.

An overview of how some of the seemingly-magical modern Linux C++ tools actually work so that you can get the most from them. C++ is a language and ecosystem that is unashamedly close to the metal, and to be an expert practitioner an understanding of compiler and OS fundamentals is essential, and this includes debugging and profiling tools. The last decade has seen a ‘cambrian explosion’ in tooling: Valgrind, perf, Address Sanitizer, rr, Live Recorder, Coverity and cppcheck have either arrived or become mainstream and even good old GDB has come a long way. Greg gives an overview of how these amazing/magical tools are implemented often exploiting a combination of compiler, OS and CPU features. Contains details on ptrace, DWARF debug info, how static analyzers work, record and replay systems - so that you can select the right tool for the job and then get the most out of it.

When programming graphical user interfaces, sometimes we might think, "Ah, I wish to have an event listener that triggers when this data member changes!" Before laughing at yourself, adding getters and setters everywhere so that you can emit a signal whenever you want, I want to tell you, your naive thought is actually the right way of thinking about that program.

If you have data, the GUI should follow the data. Data change GUI change. Two widgets use that data, two widgets change at the same time. That is, Immediate Mode GUI. This talk will introduce immediate mode GUI programming with pyimgui, a Python library that pushes the elegance of the Dear ImGUI library in C++ to a new boundary. This time, let’s think in immediate, think functional, express your program with no callbacks, and bring back the joy of programming.

The benefits of users taking control over their own memory allocation strategy have been demonstrated many times at previous ACCU conferences. However, despite these benefits and ongoing support in the C++ Standard, allocator aware software has not yet become widespread throughout the C++ community.

One of the main sources of resistance is perceived complexity when providing allocator support in our libraries, which is the prerequisite for empowering users to make choices optimal to their circumstances. This talk will tackle that complexity head-on, seeking to remove the friction between library support and user.

First, we will examine the sources of friction when writing allocator awre code in C++ today. Then, we will then suggest a small selection of potential language extensions that would permit much cleaner expression of the same designs deployed today. We aim to take the friction out of the system!

This talk provides an early preview of several language proposals we hope to send to the ISO C++ committee for C++23 and beyond; it will touch on lessons learned from an early prototype implementation; and we will discuss how to judge when the proposal and experience with it are mature enough to take up valuable committee time to move forward!

As programmers, we use APIs every day, whether it is at the library level, the subsystem level, or the individual component level. And yet, using many existing APIs is often an unsatisfying experience, for any number of reasons: poor documentation, confusing component interfaces, muddled abstractions, broken/missing functionality, etc.

So how can we distinguish between a good API and a bad API? More importantly, how can we make the argument to our managers that good APIs, whether obtained off-the-shelf or built in-house, are a prudent investment?

This talk seeks to discuss these questions and perhaps provide some answers. We’ll look at specific criteria for evaluating the goodness and/or badness of an API. We’ll cover the concepts of technical debt and software capital, and define a relationship between them and API goodness/badness. We’ll also discuss a simple iterative process for building APIs which can help avoid technical debt and increase software capital. Finally, we’ll cover some recommendations for doing evaluations, using the process in day-to-day work, and convincing management of your wisdom.

You’ve got to make a change, and the tests are passing, but you’re struggling to get the code to do what you need.

You think you can see a way…​ Maybe the code won’t compile for half an hour whilst you bend it to your will…​ And maybe your code reviewers won’t complain about the size of the change, taking them hours to review? And if you’re lucky and concentrate very hard, it will be OK. Won’t it?

As Kent Beck says, "Make the change easy (warning: this may be hard), then make the easy change."

This talk will show you techniques to be kind to yourself - and your team - by making seemingly complex edits in small, safe steps, with your IDE doing much of the heavy lifting.

You’ll be less tired at the end, and confident that the behaviour is unchanged. And users get the feature sooner - win, win!

Clang-tidy is the go-to assistant for most C++ programmers looking to improve their code, whether to modernize it or to find hidden bugs with its built-in checks. Static analysis is great, but you also get tons of false positives.

Now that you’re hooked on smart tools, you have to try dynamic/runtime analysis. After years of improvements and successes for Clang and GCC users, LLVM AddressSanitizer (ASan) is finally available on Windows, in the latest Visual Studio 2019 versions. Let’s find out how this experience is for MSVC projects.

We’ll see how AddressSanitizer works behind the scenes (compiler and ASan runtime) and analyze the instrumentation impact, both in perf and memory footprint. We’ll examine a handful of examples diagnosed by ASan and see how easy it is to read memory snapshots in Visual Studio, to pinpoint the failure.

Want to unleash the memory vulnerability beast? Put your test units on steroids, by spinning fuzzing jobs with ASan in Azure, leveraging the power of the Cloud from the comfort of your Visual Studio IDE.

Software security is scary, right? Well, no, it doesn’t have to be.

In this workshop we’ll learn, by doing, how to understand software security and the decisions we need to make.

In the Agile Security Game, we’ll work in teams, prioritising security improvements to an app-based payment application and its infrastructure. We’ll learn from the discussions and from the impact of security events following our decisions. Not only is the game fun, it also provides an excellent way of helping colleagues back at work to discuss and approach the issues of software security.

As a participant, you’ll receive instructions for how to set up similar game workshops yourself and we’ll discuss how best to introduce them in different team environments.

If you were at Angela Sasse’s ACCU 2019 keynote (https://www.youtube.com/watch?v=tBmF7ofKoYQ), this workshop picks up on many of the issues she raised. The workshop does not depend on having seen Angela’s keynote, however, and anyone can attend.

Pairs of iterators are ubiquitous throughout the C++ library. It is generally accepted that combining such a pair into a single entity usually termed Range delivers more concise and readable code. Defining the precise semantics of such Range concept proves surprisingly tricky, however. Theoretical considerations conflict with practical ones. Some design goals are mutually incompatible altogether.

Many years have passed since the release of C++11 and C++14. These standards brought many new features and idioms to the C++ language and revitalized its community. Nowadays, with C++20 having one foot out the door, it is important to look back at the experience gained using C++11/14 at scale and re-evaluate their impact. <br/>

From unexpected benefits/drawbacks to teachability issues, this talk will discuss the most significant consequences of embracing C++11 and C++14 in a company with thousands of engineers. With some healthy skepticism, commonly used features and idioms will be reassessed to uncover some unexpected pitfalls or qualities.

Thanks to the increasingly dangerous threat landscape, a large number of high profile security breaches, and the tireless work of organisations like OWASP, security is finally becoming a high priority topic in many software development projects. For many years OWASP have provided simple, practical guidance on security to software developers, their best known output probably being their "Top 10" lists of vulnerabilties for webapps and mobile development. However in recent years the explosion in popularity of application APIs has opened up another dangerous attack vector in many systems. In response, OWASP have recently developed their "API Security Top 10" list to provide similar guidance for APIs. <p> In this talk we will review the current security landscape, particularly as it relates to API-based applications, and explore the API Security Top 10 vulnerabilities in order to understand the top security threats to our APIs, which ones we might have missed in our systems, and what practical mitigations we can use to address them when we get back to work after the conference. <p> Some of this (such as logging and monitoring) will probably be familiar to those who who are already aware of the webapp Top 10, but is likely to bring a different perspective to it, while other parts (such as payload related problems) is likely to be new.

We love JavaScript, but we must admit: it’s weird. Why does this behave as it does? How does variable scope work? Why do we have such comical behavior when comparing mixed types? Let’s pull back the covers of these scenarios, and learn how it truly works. You may find a new reason to fall in love with JavaScript.

Template metaprogramming is hard. In case it is hard only for the library implementer then it is not that bad. The problem arises when it also affects the users of this library.

This talk is summarizing my experience and thoughts gathered during the implementation of the Physical Units Library for C++. The way we do template metaprogramming now results with inscrutable compile-time errors and really long type names observed while debugging our code. That is mostly caused by aliasing class template specializations of non-trivial metaprogramming interface designs. Compilation times of such code also leave a lot of room for improvement, and the practices we chose to use in the Standard Library are often suboptimal. Taking into account the Rule of Chiel while designing templated code makes a huge difference in the compile times. This talk presents a few simple examples (including the practices from the C++ Standard Library) of achieving the same goal in different ways and provides benchmark results of time needed to compile such source code.

C is often perceived as an antiquated language that is mostly used for legacy purposes, but many people still prefer coding in C or in a subset of C++ that is very close to C.

This is sometimes labeled "Modern C" and the ideas behind it are becoming more popular alongside other paradigms such as Data Oriented Design (DOD), Zero Is Initialization (ZII) and Centralized Memory Management (CMM).

In fact, many new systems programming languages, such as Rust, Go and Zig, also embody a lot of similar ideas as Modern C showcasing a high degree of interest in these paradigms.

In this talk we will explore how programming looks like with this different approach to C and how it addresses matters such as API design, error handling and resource management as well as what are the benefits and costs of these techniques.

By the end we will gain a better understanding of how these ideas can help improve the quality of our code, what new languages have adopted similar concepts and to what extent, and what lessons we can learn from this in order to improve our own existing codebases and styles of coding.

Which for a session title at a tech conference isn’t what you expect. And this isn’t what you expect from an abstract. The session probably isn’t what you expect either.

Of course, to look at me, you wouldn’t realise half the problems I deal with, because a lot of the time I’m hiding behind the logic of code, and the shield of electronic communication. Turns out you wouldn’t realise it with most people. We’re fun like that.

In this session we’re going to look at neurodiversity. What it can mean for your team. What it can mean for you; regardless of if you classify yourself as neurodiverse or not. You can join in, or you can sit and listen. It’s up to you. The idea is to have fun, share ideas, and learn.

In modern societies, more and more paper documents and ink signatures are replaced with their electronic equivalents. Now the ascent of quantum computing threatens to render all current digital signature systems insecure. Hash functions, however, seem to be quite resilient to quantum attacks and thus a promising building block for future cryptographic protocols.

The talk will recap the essentials of the existing digital signature systems as well as cryptographic hash functions and then show how the former can be built from the latter. Curiously enough, a digital signature system based on hash functions was one of the first to be invented when the idea of asymmetric cryptography was introduced to the world!

In addition to reviewing the most important historical systems, the talk will also cover a brand new one developed over the past few years.

C++20 comes with Concepts - one of the four major features of the C++20. This talk will explore a basic introduction to what Concepts are, how to use them and how to write one. The talk will also focus on how they compate to "adjacent" language features such as Rust Traits, Haskell Typeclasses and Swift Protocols. This talk will be a "must see" for programming language enthusiasts.

Writing reliable and maintainable C++ software is hard. Designing such software at scale adds a new set of challenges. Large-scale systems require more than just a thorough understanding of the logical design concepts addressed in most popular texts. To be successful on an enterprise scale, developers must also address physical design, a dimension of software engineering that may be unfamiliar even to expert developers.

More than two decades in the making, Large-Scale C++, Volume I: Process and Architecture, is finally here! Drawing on his over 30 years of hands-on experience building massive, mission-critical enterprise systems, John Lakos — using select excerpts from this glisteningly new volume — elucidates the essential value of (and several techniques needed for) creating and growing hierarchical reusable software, a.k.a. Software Capital, as the foundation for developing C++ software at virtually unbounded scale.

This is not a comment on mathematics per se, but on the consequences of having an inappropriate model of the work we do.

Programming is an inherently mathematical discipline. The supporting raw electronics and computing components only follow simple rules, yet have the capacity for the most complex outcomes. For these systems it is clear that having a good mathematical intuition of the properties of such components is essential for any in depth work.

I propose that this paradigm remains relevant as we move up to higher abstractions in the computing stack towards the realm of the human elements and the projects they conceive.

I will visit a number of models, which either have heuristics or suggest processes, and discuss if, how and when they benefit us when applied to programmers and products.

Finally, if there is a suggestion for the optimum course of action when applying a model, this implies a penalty for applying a less apt model, or applying the better model, but skipping more appropriate processes. Less tactfully: what happens when we get things wrong?

Given this will be a topic in which everyone in the room will be an expert, expect some audience participation!

In this presentation, the focus will not be on code but on what most developers will face at one time or another and that is having to redesign and replace an existing legacy system.

Production code written in the "Dark ages" with a large user base is hitting its limits in terms of performance, testability and maintainability.

This talk looks at what determines when a product needs a partial or full rewrite. What tools and ingredients are needed before you start and how to get rolling. We will also examine the perils and pitfalls of the various stages in the redesign of a legacy system that can slow down or even derail getting the Product out the door and how to avoid them. Finally we will examine how to navigate the nightmare of rolling this new software out to the existing user base.

Although the real world examples draw primarily on systems written in C++, the above can be applied to most any complex system being developed by a Team of developers.

C++20 is set to add new facilities to make writing concurrent code easier. Some of them come from the previously published Concurrency TS, and others are new, but they all make our lives as developers easier. This talk will introduce the new features, and explain how and why we should use them.

The evolution of the C++ Concurrency support doesn’t stop there though: the committee has a continuous stream of new proposals. This talk will also introduce some of the most important of these, including the new Executor model.

These include std::jthread, which provides automatic joining of threads, std::stop_token for cooperative signalling of shutdown, std::latch for notifying when a batch of operations have completed, std::barrier for multithreaded loop synchronization, and std::counting_semaphore for general, flexible synchronization

For typical interactions we are used to processing values represented in decimal. Computers are much more versatile processing using binary representations. As a result it is quite common that decimal values are processed using a binary presentation. Sadly, doing so does cause problems when fractional values are involved.

This presentation explains the representation of floating points in a computer and analyses typical problems encountered when using binary floating points to represent decimal values. It then describes alternative representation, in particular decimal floating point and decimal fixed point, and why these solve the relevant problems.

A decimal fixed point representation is the preferred approach when the number of fractional digits used in an application is known. However, that is often not the case. Thus, the design of a library implementation for decimal floating point is discussed.

This talk describes an approach for combining C++20 with Lua. A key benefit of this combination is its flexibility i.e. performance critical features can be implemented in C++, whereas, behavioural aspects can be expressed in Lua. As Lua is interpreted, the program’s behaviour can be changed on-the-fly or in the field without a compilation environment. Thus, hypotheses can be tested, workarounds can be explored and previously unknown requirements can be accommodated without requiring a full release cycle.

This session presents the technical details for how to implement such an architecture. The aim of the session is to provide the audience with enough knowledge to be able to implement these ideas in their own projects. In particular, the session will show how to use SWIG to generate bindings and type mappings between C++20 and Lua, how to combine Lua coroutines (which are stateful) with stateless C++20 coroutines and how to integrate SWIG, Lua and C++20 into a CMake build flow. SWIG type mappings (with code available on GitHub) are provided for: std::span, std::any, std::optional and std::variant.

This presentation is a significantly updated and expanded follow-on to a talk given at CppOnSea 2020. Audience members do not need to have seen the CppOnSea talk i.e. the session is completely standalone. However, those that have seen the CppOnSea presentation will benefit from the new content, in particular, the update to C++20, the new SWIG type mappings and a more comprehensive treatment of the interplay between C++ and Lua coroutines.

A further benefit is that these ideas have been tested in a large commercial deployment. As a running exemplar, the talk will describe how Blu Wireless (the author’s employer) has migrated a mission-critical application from a monolithic C++98 code-base to the C++20/Lua architecture described here. In addition to the talk, the author will provide a C++20/Lua application called 'LuaChat' (available on GitHub) to consolidate the concepts and to provide a basis for audience experimentation.

C++20 is probably the biggest change to the language since ever. In this session, we will look into some changes that templates received with C++20. The biggest change is the introduction of Concepts. We don’t stop there. We will also talk about improvements to CTAD and NTTP and smaller improvements like explicit(bool). Of course, we will also look into how templated lambdas work in C++20.

By the end of the talk, attendees have learned about the newest C++20 template updates and how to apply them.

There must be few codebases that don’t face some sort of cross-platform or multi-platform challenge. The size of the challenge varies. At its simplest it might be just to get your system working on a limited number of different releases of the same operating system running on the same processor architecture. Or perhaps you’ve been asked to make your Linux application run on AIX - a job filled with snake Dpits to trap the unwary, as anyone who’s crossed swords with AIX will know. And at the extreme, you may be faced with cross-compiling from a variety of host operating systems to target multiple very different operating systems, GUIs, processor architectures and toolchains.

Judging by some of the open source libraries I’ve been working with recently, this isn’t an area that’s commonly done well.

This aim of this session is to share techniques and experiences of organising and building multi-platform and cross-platform code. I’ll be looking at the common approaches to multi-platform and cross-platform coding and how some build tools I’ve experienced deal with it. There will also be a bit of a rant about GNU Autotools and the perils of system introspection.

But mainly I want this to be a highly interactive session. I want to hear from you, and your experiences meeting the same challenge - what are the tools and techniques you use, what are their good and bad points? Let’s improve our portability together.

Multithreaded programming is everywhere nowadays. However, the way we construct multithreaded programs is still largely primitive; similar to using gotos in the era of structured programming. The current methods have usability, composability, correctness and also performance problems.

This talk aims at providing a new toolset for the multithreaded programmer. Instead of writing our multithreaded programs in terms of explicit threads and synchronization primitives, one should be expressing them in terms of tasks and dependencies between tasks. The talk describes a method of modeling the programs and dependencies. It also shows how one can eliminate locks (or any synchronization primitives) from programs. Using this method, one can raise the abstraction of multithreaded programs, bring back composability, improve determinism, and also improve performance.

The talk will be a mix of theory (presented in an intuitive manner), comparisons with other models, practical examples, and, of course, performance considerations.

Lambda expressions first appeared in C++11 and have been extended slightly in each revision since then.

I will be taking a look at lambdas and trying to answer questions such as these: - what are they? - when should I use them? - how do they work? - what are some of the pitfalls?

I hope that anyone who knows C++ will be able to follow most of the content, and increase their understanding of this part of the C++ language!

There is a glaring omission in the standard library: there is no built-in support for linear algebra. This has lead to languages like Python becoming ascendant in machine learning and artificial intelligence.

This is a strange situation to find ourselves in. C++ is the default choice for high performance applications. For example, in the real-time rendering of 3D games, millions of linear algebra calculations are performed each second, and yet each game must create or choose a maths library for geometry and coordinate transformation.

In this talk I will discuss the need for linear algebra, the typical requirements of a linear algebra library, and the proposal I am co-authoring to add linear algebra types and syntax to the standard library. I will present examples of simple applications in geometry and colour manipulation, and consider interaction with BLAS, the industry standard FORTRAN/C linear algebra library, with a view to implementing the new types and syntax.

This is a new talk reflecting the current status of the proposal.

The idea of limited work-in-progress (WIP) is coming from Lean methodologies. At its core it means that new tasks should only be started when the current piece of work is done and delivered. Finding the right work-in-progress limit can increase overall system (organisation) throughput. This idea can be applied on many levels including writing code. In this live coding session I will write FizzBuzzWoof code kata in Kotlin showcasing software development workflows which can be used for limiting work-in-progress. In particular: change size notifications, auto-revert, TDD, TCR (test && commit || revert).

Learning outcomes: Details of workflows that help minimise work-in-progress while writing code. Prerequisites: Basic knowledge of a programming language similar to Java/Scala/Kotlin.

A high performance, just in time compiled dynamic language, which gives python like productivity with C/C++ style performance. We will get into the details of why this seemingly impossible task was made possible through clever language design. Then we will geek out by generating LLVM byte code and x86 assembly code for individual functions interactively at the command line, explore meta programming with Julia’s LISP style macros and learn about Julia’s powerful multiple dispatch mechanism and how it differs from function overloading.

Julia is an upcoming language being embraced by the scientific and high performance computing community, running projects like Celeste on 650 000 cores processing 178 terabytes of astronomical data.

With C++20 we will have a new basic thread class, std::jthread. It will fix a few flaws of std::thread, which was not designed as an easy to use RAII type and lacks the ability to support stopping a running thread. Sounds like we only have to implement a better destructor and add a parameter to signal cancellation. But especially with concurrency the devil is in the details. This is not just a talk about jthread. It is a talk about how implementing even pretty simply concurrency requirements can become a tricky task with many many traps.

“The worst part of this whole topic is that the people who hate singletons rarely give concrete suggestions for what to use instead.”

In this talk, we will explore just such an approach for replacing the Singleton pattern in large codebases.

It is easy to slip into the pattern of creating singletons - particularly in large legacy code bases - where low level functions need to propagate side effects like database updates, IPC etc.
Passing parameters down long function call chains can be daunting in terms of scope of change required in a large codebase.
Additionally, users calling a long established API in legacy code are frequently unwilling to change their calls to supplement the current data being passed in.

After briefly reviewing a classic singleton approach to a typical problem – sending requests to a server – and it associated drawbacks. We will rework the example and replace the function’s internal singleton calls with calls to an explicitly passed in wrapper class. The extra information required for legacy users is injected via a custom default instance of the wrapper so that the users of the original function require no coding changes.

We will then show how the previously untestable function can now be subjected to unit testing via dependency injection.

This idea is later expanded to cover

This alternative approach has been successfully employed in multiple areas in Bloomberg where developers believed there was no other feasible choice.

These unusual times, of sudden change and uncertainty, remind of the relevance of Complexity in the modern organisations and work environment. This session presents examples and an overview of practices inspired by Complexity, to be employed every day in software and digital products development. It also outlines the landscape of Complexity inspired practices, organised in three major regions: the teams, the work to do, and the whole organisation. These practices provide a new means to gradually introducing our co-workers, our teams and our organisation to Complexity. They exemplify a new approach that consists of acting our way into the new Complexity thinking. This new approach shifts up-side-down the centre of gravity of the conversation around Complexity from the theory to the practice. It puts the practice front-and-centre. And it wants to engage hands-on practitioners and tinkerers. All the practices presented are based on social complexity and anthro-complexity. Therefore, they fully recognise the unique qualities of the human element. And that we are not algorithms, cellular automata, nor hives. Complexity science with Lean and Agile Software Development are the three pillars of modern ways of working. So this session is relevant to any serious Agile practitioner. This session is based on the new book Living Complexity. It is interactive and includes online activities and conversations.

C++ developers are famously bad at naming: our idioms, guidelines, and lore are rich in examples of terrible names. For example, consider RAII, which stands for scope bound resource management, or west const which perhaps should be const west, or all the samples that feature an object called x which is an instance of a class called X, and so on.

The good news is that naming well is a learned skill, and you can learn it, and start to name better right away. In this talk, I’ll tell you why names matter, what benefits a good name can bring, and how to be better at naming. I’ll discuss some categories of names and some common decisions within those categories. I’m not going to give you a set of rules to follow: this is about thinking and considering the meaning of the things you are naming. I will give you some questions to ask yourself and some structure that I use to help me to help those who read what I write.

I’ll also address renaming things in existing (legacy) code, why and when to do it, and why getting it right the first time may not even be a realistic goal. You should be a lot more confident naming things after we spend this time together.

The SOLID principles were first grouped together by Robert Martin over two decades ago - but the principles themselves are much older. A solid basis for good design (pun intended)? Perhaps. But in recent years there has been increasing talk that they are internally redundant, too focused on OO, or just missing the mark in other ways.

So are they still useful? Is it worth teaching them? Is there a better set to go by? Do we need a new acronym, perhaps referencing a different state?

After a brief history, and a refresher on what the SOLID principles actually are, we’ll weigh up some of the criticisms that have been levelled by others, maybe add some new ones, the look at some ideas for a way forward. Bring you opinions - I want to make this somewhat interactive, as well.

Computer scientists are bad at relationships. Nearly every program crash is rooted in a mismanaged relationship, yet we spend most of our time discussing types and functions and not the relationships connecting them together. This talk looks at common ways data and code are connected in an application, how those relationships are typically represented, and the problems caused by the use, and misuse of these paradigms. Then we’ll look at ways to model these relationships in C++ and use them to build correct applications.

Each and every C++ programmer uses templates. Containers such as vector<> or array<>, strings, algorithms such as sort(), iterators, and I/O streams are all implemented as generic code. Modern C++ adds type traits, smart pointers, template member functions such as emplace(), and generic lambdas as a tricky form of generic code.

Nevertheless the knowledge and understanding of how to implement and use templates is very limited and each and every programmer is sooner or later getting lost.

This workshop therefore discusses templates for a whole day to make clear what it means to use templates and how to use them in practice. The focus is on Modern C++ demonstrating the benefit of using the language features of C++11, C++14, and even C++17. As a result the general understanding of templates will be improved and generic code might become more helpful and less surprising.

Outline: We go through the standard template topics (function templates, class templates, non-type templates, specialization and other tricky basics) and spice them with the modern language feature to do up-to-date template programming. Then special modern features come into play: move semantics, variadic tempates, fold expressions (C++17), class template argument deduction (C++17). Finally some special consequences: polymorphism with templates (including using std:variant<>), type utilities, SFINAE, and a bit on metaprogramming.

C++ Concepts is one of the most significant and long-awaited features of C++20. 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 make them much more user-friendly when they occur. The workshop will describe this C++20 feature, its similarities and differences from Concepts TS (provided with gcc-7), and will present ways to benefit from a significant part of the functionality in current production C++ projects with the usage of "legacy" C++11 features.