ACCU 2019 Sessions

Hashing values is an important technique for efficient associative containers. It has multiple independent dimensions of considerations. None of these considerations is generally well understood. This presentation scratches the surface of the following areas:

The creation of containers and hashing functions is typically done by specialists. The primary intention of discussing them is to give an idea why applications should stay away from custom implementations. On the other hand provision of hash values for user-defined types is rather common-place to support their use as keys of associative containers. Thus, this presentation will have an emphasis on the important aspects for providing hash values for user-defined types:

The code examples use C++. However, the various considerations are language independent and their understanding will be useful when using other programming languages, too.

As a developer, you must spend more time reading code that writing code, don’t you?

Being able to quickly make sense of a piece of code you don’t know, whether when discovering a codebase, performing a code review, or reading code you wrote a while ago, is an extra-useful skill to have in your daily work.

This presentation will teach you 10 techniques to achieve this, in C++ or other languages. Some of them are classical techniques of programmers, some are classical techniques coming from other fields (e.g. reading books) applied to reading code, and some are novel ideas.

If you read unclear code on a daily basis, like legacy code for instance, this presentation will give you tools that you can use to be more productive as soon as you’re back to the office.

The safe systems programming language "Rust" by Mozilla is all the talk these days. From noalloc embedded systems, via command-line tools all the way to distributed networking services, Rust is being used to make systems more reliable and scalable.

Rust does this with certain guarantees that are given to you as a developer at the compile-time of your program. This includes memory-safety, thread-safety and many zero-cost abstractions. But how does it all work? And more importantly, how can you use it, without having to reboot your entire project while also having to learn a completely new language?

This workshop will give you a detailed look at the Rust programming language and its capabilities. From the concurrency-aware type system to library linking behaviour, many beginner to intermediate topics will be covered.

We have developed our own File Server by using a SMB2/3 implementation running on Windows in User mode; it’s easier than writing a Kernel-Mode File System driver! This has now been open sourced using an Apache 2 license. We are hoping to build a community to build FUSE for Windows.

This presentation will demonstrate the power of running Virtual File Systems in user mode, with plenty of live examples of doing things that you just can’t do in a normal filesystem – like embedding a database (remember WinFS anyone?).

This talk then progresses to discuss the power of allowing programable recipes in filepath names. To explain, one example Filesystem driver enables the generation of media files to order - Just in Time rather than Just in Case. We will demonstrate adding the power of a Python interpreter to our VFS, and discover the power of allowing simple composable functions as folder names. We are programming the filepath.

The presenter will include multiple live demonstrations of the techniques he has invented using these technologies during the talk. Learning Objectives:

Banks have always invested heavily in technology, and, in the past, have often pushed technical boundaries in an effort to measure their risks better and more quickly. But what looked like big, modern system in the early 'naughties is now dwarfed by cloud technology, and banks are hampered by the crippling technical debt of decades invested in legacy systems and libraries.

Even some of the more radical new systems are seem to be merely updated implementations of ideas first pioneered in the 80s.

What would a scalable financial risk platform look like if it was started from a clean slate, with modern tools and software engineering techniques? This talk looks at architectural principles, prototypes, problems and solutions.

This is an all-day pre-conference tutorial. But unlike the other tutorials, this Early Career Tutorial is exclusively for software developers in their first years of work. You have had some experience of professional programming, whether as a placement student or a graduate level employee. You may be wondering if the ACCU conference is for you and how it can help you. 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, drawn from a rich history of previous ACCU conference material. Your tutors will be a variety of experts chosen from among well-known speakers for their excellent content and delivery.

This tutorial is chaired by 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 is now a lecturer in programming and cyber psychology at Bournemouth University.

Sessions will include a mix of personal and technical skills:

Technical presentations present their own particular challenge. This session will help you to communicate effectively the information you have to share.

The high level structures of a software system play a key role in making developers' lives harder or easier, as do the processes within which they work. This session will help you to look at the bigger picture with an expert eye.

The obvious part of programming is to get the computer to do your bidding at all! This session will move beyond that to help you reflect on coding practices. ACCU’s tagline, after all, is "Professionalism in Programming".

Code reviews are at their best an invaluable part of the development process and at their worst not only a waste of time but also harmful to working relationships. This session will help you to benefit from the best version and avoid the pitfalls of the worst.

We spend a lot of time dealing with bugs - whether our own or other people’s. Unfortunately much bug hunting is frustrating, haphazard, inefficient, and resource intensive. This session will look at some principles and strategies for making bug hunting more effective and less of a 'black art'.

The day will end with your very own lightning talk session, the ideal opportunity to practice sharing your thoughts with a small, friendly audience.

We all know that writing tests for our code is “what we should do”, and maybe we’re even doing that already. But it feels like extra busy-work that slows us down – and they hardly ever catch any bugs anyway…

Maybe we’ve even tried TDD, and felt that it was just adding even more ceremony to the problem with no real advantages.

But the advantages are definitely there! We just need a good grounding in what TDD actually is (and isn’t) and how to do it properly – especially in the context of C++, which brings it’s own idiosyncrasies and bottlenecks to the matter.

That’s what this workshop aims to be. Whether you’ve never written a test before, or you’ve had some mileage with TDD already, be prepared to ratchet up your productivity by thinking about things in new ways and gaining more approaches to breaking down problems in sustainable ways.

The performance benefits of supplying local allocators are well-known and substantial [Lakos, ACCU’17]. Still, the real-world costs associated with orchestrating the integration of allocators throughout a code base, including training, supporting tools, enlarged interfaces (and contracts), and a heightened potential for inadvertent misuse cannot be ignored. Despite substantial upfront costs, when one considers collateral benefits for clients – such as rapid prototyping of alternative allocation strategies – the case for investing in a fully allocator-aware (AA) software infrastructure (SI) becomes even more compelling. Yet there remain many “concerns” based on hearsay or specious conjecture that is either overstated or incorrect.

In this densely fact-infused talk, we begin by introducing a familiar analogy to drive home the business case for AASI. Next we identify four syntactic styles based on three distinct models: C++11, C++17, and a brand new language-based approach being developed by Bloomberg for C++23 (or later). Costs – both real and imagined – will be contrasted with performance as well as other important (“collateral”) benefits. The talk will conclude with a closer look at the economic imperative of pursuing a low-cost language-based alternative to AA software in post-modern C++.

Chip speeds are not increasing, but the number of cores is, so the path to better performance is concurrency. But writing concurrent code is hard.

In this introduction to asynchronous programming, I’ll give you an outlook on high-level abstractions that will help you avoid the most common traps associated with locks and atomics.

I’ll use a series of code examples from our production to illustrate just how subtle race conditions can be. I’ll also share strategies that find these problems and better, avoid them in the first place and show that using high-level abstractions don’t result in performance loss.

The talk will cover the following topics:

When building software, we often need to associate metadata with the code we’re writing. A typical example is when we need to tell our linters to ignore a specific range of code. A common approach to adding this metadata is to embed it directly in the code using the syntax of the language, but this approach has a number of drawbacks including language specificity, potential for collision, and cluttering of the code.

In this talk we’ll look at an alternative approach that stores the metadata separate from the code using a technique called anchoring. The metadata is associated with an anchor, a region of code inside the source file. Critically, the anchor also includes a context, a snapshot of the code surrounding the anchored region. As the source code is changed, this context – along with some very interesting algorithms for aligning text - is used to automatically update the anchors.

To demonstrate these concepts we’ll look at spor, a tool that implements anchoring and anchor updating. The primary implementation of spor is in Python, so it’s very approachable and, indeed, open for contribution. As a side note, we’ll also look at a partial implementation of spor written in Rust. Finally, we’ll look at how spor is being used in Cosmic Ray, a mutation testing tool for Python.

Apps and services often build features with good intent, trying to improve interactivity or connections between our users. But what if one of your users has a stalker, or an abusive ex? You may have given them another way to hurt or harass your user.

This session is a look at some common threat models – who is at most at-risk, and who is a threat to your most vulnerable users.

The point of this session is to emphasise "this is a problem you need to think about", not offer silver bullets or lots of solutions.

Today, almost every computer, tablet and phone comes with audio input and output. Computer games and many other kinds of applications would be unthinkable without sound. Yet, the C++ language has no notion of it. Literature on audio in C++ is sparse. For even the simplest possible audio functionality, programmers need to deal with a confusing landscape of complex platform-specific APIs and proprietary 3rd party libraries. But audio in C++ doesn’t have to be hard!

First, we show how audio signals can be digitally represented in C++, covering basic concepts such as channels, audio buffers, PCM, and sample rate. We explain the principles of communicating with your soundcard and playing, recording, reading and writing audio data. In the second half of the talk, we will discuss a proposal to add a minimal, modern audio API to the C++ standard library. We will show the basic design, the current state of the implementation, and simple example apps. We finish with an update on the current state of this proposal.

Creating a quality web application is hard. It’s hard to gain customers, it’s hard to build your reputation and it’s hard to keep the costs low. Nevertheless, security is often an afterthought.

However… Have you considered the cost of fixing security issues later? What about the reputational damage of a security breach? Are you worried about your customers’ data?

We will talk about good security coding practices for web applications and how to apply them early on using some real world examples. We will also help you to think about your website’s vulnerabilities from the view of a hacker.

In this talk I will explore best practices when accessing data on local or shared file systems. Examples of what can go wrong taken from real customer problems will be used to back up how simple guidelines and good use of available tools can make a massive difference to the performance, reliability, scalability and portability of your code. Data doesn’t have to be big to cause a problem, but as data sets grow, the way we access data has never been a more important consideration. Our customers work in scientific and high-performance computing with different trade offs to make between time-to-market, reliability and performance, but what they all have in common is that they have to care about I/O.

C++ the language has developed faster than C++ the library. So, whilst there are many ways to initialise an object, there’s no standard way to parse a command line, let alone to serve a website. Fortunately the Boost libraries exist to fill the gap, extending the range of functionality available to C++ programmers.

Boost is no panacea. Although its libraries are extensively reviewed and tested, they sometimes seem designed to show what can be done with C++ rather than what should be done. Some libraries could double up as compiler test suites, exposing toolchain performance and conformance issues. Using Boost means builds take longer and upgrades require attention.

As a result, the code bases I’ve worked on have either avoided or cherry-picked from Boost, often preferring to hand-roll functionality present in the libraries. Recently, though, I have been working on a code base which uses Boost unreservedly.

This code base is a search engine which uses natural language processing (NLP) techniques to locate information in unstructured medical narratives. It’s largely the work of a single programmer, and could not have been constructed without leaning on Boost for graph processing, parsing, memory-mapped files, logging, serialisation, exposing a Python API, and also its extended suites of containers, algorithms and utilities.

This case study explores in detail the use of Boost in this codebase. Although the code is proprietary, I will present real code showing how the libraries fit in and what they do. To provide context, there’ll be an overview of some NLP and search techniques. The session will provide a practical introduction to several of the Boost libraries, and an honest reflection of my experience in using them.

The code examples used in the session can be found in this GitHub repository.

The C++ Pub Quiz is back! So join us on a fun tour passing by the light, the dark and the tricky corners of C++! You will be working in small teams where I present code snippets in C++ and you will discuss, reason about and sometimes need to guess what the code snippet will print out. All snippets are educational and we will elaborate on the basics, the advanced and new parts of C++.

When legacy code is mixed with modern language features and patterns, when the rich heritage of C++ and its compatibility restrictions co-exist with the adoption of best practices from other languages and technologies, some of us C++ developers become lost and need to follow and stick to a more conservative path. Recent independent research studies show that developers are staying with C++11, only slowly moving to C++14 and rarely adopting C++17. They tend to avoid using unit testing frameworks, are barred from throwing exceptions, and often still build packages manually. Alongside the areas where strict limitations are imposed on the subset of the language used, there are others, like game development, that find workarounds to emulate language features not yet accepted to the language standard. What are the real reasons for this state of affairs, what biases might be at play, and what are some of the improvements planned?

In this talk, we will overview the C++ ecosystem based on several independently conducted research studies, identify the common aligning trends across all the sources, and analyze the reasoning behind them.

Importantly, we’ll see how the work of the C++ committee and tooling evolution can help overcome these difficulties and usher in a brighter future for C++. We’ll get a glimpse into some of the most valuable recent proposals and changes to the language, and see how tooling is helping, or can help, move to newer standards faster.

Many modern CPUs provide an extremely rich set of instructions and features that enable some highly specialised optimizations for particular use cases.

This talk takes an educational problem and investigates whether we can optimize the representation of our problem in a way that allows for a much higher performance solution than an "obvious" solution in a generic programming language, such as C++, might achieve.

Our example problem will be the evaluation of poker hands, looking for the optimal way to test for straights, flushes, full houses using all the features of a reasonably modern x86-64 architecture CPU.

We’ll have a brief tour of some of the available SIMD instructions and their performance benefits and the costs of manipulating our data into a form where they can be used.

Finally we will pose the question: is it possible to meet the performance of our custom solution using "generic" C++ and an optimizing compiler?

Due to the complexity of the language and the presence of some low-level language features, "Clean C++" seems to be an oxymoron for many developers. Especially in enterprise land, C++ applications tend to have large code bases grown over several years. Those legacy code bases tend to suffer from underdeveloped or missing unit and integration tests. Development teams maintaining such code bases resign over time and adopt "don’t touch it, you’ll break it" policies.

Nevertheless, it is possible to write clean C++, to refactor even large code bases as needed and cover critical parts with automated tests. The key elements to successfully regain control over code quality are a dedicated team and a set of properly sized and prioritized steps towards that goal.

In this talk, we’ll touch a few important topics about cleaning up a code base. This includes knowing when and where to do the refactoring, what strategies to use, and to bring the team on the same page.

In the end, there is the question of tooling or its absence. Especially when a C++ code base is tied to an old compiler and IDE for some reason, there still are ways to let the compiler and other tools help us.

Error handling has fractured the C++ community into incompatible dialects, because of long-standing unresolved problems in C++ exception handling. Many projects turn off exception handling (EH) entirely, such as with -fno- except. Many others don’t throw exceptions in code that has to run in statically bounded space or time. Still others don’t know exceptions in code that may not be exception-safe, because they cannot see the invisible exceptional control flow paths.

This talk summarizes the root causes and presents some early proposed solutions that we hope will let the community embrace using exceptions consistently for unified error handling. It also discusses the differences between program-recoverable errors (e.g., database connection dropped), program bugs (e.g., precondition violation), and exceeding resource limits (e.g., stack overflow) to demonstrate why these are three fundamentally different things with different audiences, and therefore should be reported in different ways. The talk will also cover what’s already going on in C++ standardization today to evolve the standard library in these directions, including what’s now already in C++20 to lay the groundwork for these coming changes.

TBA

This short talk presents how easy it is to replace some cases of dynamic polymorphism with std::variant. During the lecture, we will analyze and compare a few implementations of the same simple Finite State Machine. It turns up that variant-based code is not only much faster but also it gives us the opportunity to define our interfaces and program flow much better. The talk will end up with the discussion of pros and cons of each approach and will try to give guidelines on when to use them.

The C++ 20 object and memory model has no support for memory allocated from, or managed by, elsewhere to the currently running C++ program. This makes it impossible to legally write a dynamic memory allocator which uses memory not available to the C++ program when it began life, so global operator new in every hosted C++ implementation today relies on undefined behaviour. For similar reasons, shared memory, memory mapped files, or even virtual memory, cannot be legally used in C++ programs without relying on undefined or unspecified behaviour. P0593 Implicit creation of objects for low-level object manipulation "solves" this by enabling the C++ program to tell the compiler "trust me, I’m the programmer", which is a useful stop-gap, but it leaves one wanting for something better.

This talk will recap the C++ 20 object and memory model, illustrating the mismatch between reality on the ground for the programmer for over twenty years, and the C++ programming language. We will look at the next generation of storage devices which directly expose to the host computer the on-device internal filing system (e.g. the Samsung KV-SSD), such that i/o is exclusively key-value load and store operations, rather than reads and writes of bytes. We shall muse on how a future C++ object and memory model might be adjusted to more closely match hardware and kernel reality.

Programmers, it turns out, are human beings. This means they not only feel emotions, they leave traces of those emotions behind in their code. Kate will show you why that is so, and what you can do about it.

Machine learning is a massive topic, but it is possible to cover some interesting and useful aspects in a day’s workshop. For example, inspired by the biological process of evolution in nature, evolutionary algorithms have been widely used for optimization problems, i.e. searching for the ‘best’ solution(s) to a problem from a space of possibilities. This day-long interactive programming workshop is aimed at programmers with reasonable competency in Java who wish to better understand a variety of evolutionary algorithms and program them using a framework.

The workshop begins with a brief introduction on evolutionary algorithms and their history, and how they have taken biological evolution as inspiration. Rather than ‘re-inventing the wheel’, the workshop then examines some of the freely available frameworks for optimization with evolutionary computing.

Taking the open source Java Class Library for Evolutionary Computing (JCLEC) (http://jclec.sourceforge.net), workshop participants start to program with the framework to address a variety of optimization challenges such as:

Participants will also be encouraged to bring their own specific problems to the workshop for the workshop to discuss and work together to find good ways to solve them by programming with evolutionary algorithms. Specific participant problems could involve optimisation problems such as, for example, timetabling, route finding, load balancing etc. etc.

By the end of the workshop, participants will have gained a practical understanding of the important patterns of evolutionary algorithms (e.g. solution representations, fitness measures, diversity preservation operators), and know how implement the components via a framework.

Participants are strongly encouraged to download and install the JCLEC framework before attending this programming workshop and bring their own laptop with a Java development environment installed.

In the last few years, Clang has opened up new possibilities in C++ tooling for the masses. Tools such as clang-tidy and clazy offer ready-to-use source-to-source transformations. Available transformations can be used to modernize (use newer C++ language features), improve readability (remove redundant constructs), or improve adherence to the C++ Core Guidelines.

However, when special needs arise, maintainers of large codebases need to learn some of the Clang APIs to create their own porting aids. The Clang APIs necessarily form a more-exact picture of the structure of C++ code than most developers keep in their heads, and bridging the conceptual gap can be a daunting task.

Tooling supplied with clang-tidy, such as clang-query, are indispensable in the discovery of the Clang AST.

This talk will show recent and future features in Clang tooling, as well as Tips, Tricks and Traps encountered on the journey to quality refactoring tools. The audience will see how mechanical refactoring in a large codebase can become easy, given the right tools.

A medium size team, on a monthly release cycle, for a mature commercial product developed for almost 15 years. About a year ago we decided to join the rest of the Universe and switched from SVN to Git. What could go wrong there ? Centralized workflow, feature branch workflow, GitFlow, forking workflow, OneFlow, No flow ?! Oh my ! To rebase or not to rebase ? That is the question. Prepare yourself for an equal amount of stories, gotchas and workarounds, both on the developer side of things, as well as the DevOps maintenance nightmare of CI/CD pipelines for testing, validation, daily builds and other necessary gears. Please join me for a quick tour of a blatantly honest case-study on using Git / GitLab and related tools in a dynamic development team. Spoiler: no unicorns here.

In this hopefully light hearted and amusing keynote, Paul Grenyer will chart his journey from over excited puppy who needed to be hit over the nose with a rolled up newspaper to helping build one of the strongest and most successful tech communities in the UK in the massive tech hub of Norwich, still considered an insignificant back water by many.

He’ll start by asking the question, why Norwich and help you understand one of the most misunderstood places in the UK. How a disperate, but highly talented tech community was brought together and runs three tour de force tech events every year and countless other tech related events to become recognised by TechNation as one of the strongest independent communities in the UK.

Of course it wasn’t all plain sailing and Paul will look at the egos, politics and pitfalls of building a community like this. Just like so many of the software projects we work on everyday, there’s always more which can be done.

Parallel programming can be used to take advance of multi-core and heterogeneous architectures and can significantly increase the performance of software. It has gained a reputation for being difficult, but is it really? Modern C++ has gone a long way to making parallel programming easier and more accessible; providing both high-level and low-level abstractions. C++11 introduced the C++ memory model and standard threading library which includes threads, futures, promises, mutexes, atomics and more. C++17 takes this further by providing high level parallel algorithms; parallel implementations of many standard algorithms; and much more is expected in C++20. The introduction of the parallel algorithms also opens C++ to supporting non-CPU architectures, such as GPU, FPGAs, APUs and other accelerators.

This talk will show you the fundamentals of parallelism; how to recognise when to use parallelism, how to make the best choices and common parallel patterns such as reduce, map and scan which can be used over and again. It will show you how to make use of the C++ standard threading library, but it will take this further by teaching you how to extend parallelism to heterogeneous devices, using the SYCL programming model to implement these patterns on a GPU using standard C++.

A 40 minute introduction into The Go programming language. Go is designed to be a simple language that’s easy to grok. In this session we’ll quickly cover the basics of the the language before diving into some of the more fun aspects such as concurrency, and its use with Docker. We’ll also look at some of the gotchas the language has so if you’ve already dabbled we’ll help you go get better.

What if you could reuse code, umm, almost everywhere? Kotlin strives to work on all platforms, and can be elegantly leveraged to write code once, and share between several platforms, thereby eliminating the need to write duplicate code for the same core components in different platforms. In this talk, we shall learn how to architect and implement a multiplatform project for android and iOS, and on the way, shall also dive into several exciting concepts like Kotlin/Native, coroutines, etc. to build up the complete picture.

A workshop to learn Kotlin from scratch, oriented to Java or C# developers. After a brief introduction to Kotlin syntax, we will work through all main features of Kotlin Language using unit tests of increasing difficulty. The course is self paced but there will be support in case of difficulties and space for discussion.

You need to bring your own laptop with ide configured for kotlin, pairing is also fine.

Haxe is a strictly-typed (and type-inferring) programming language with a diverse set of influences, including OCaml, Java and ActionScript. Its syntax will be familiar to anyone who’s worked with modern OO languages, however it has features you’d expect in a meta language, such as: everything’s-an-expression, compile-time code manipulation and pattern matching. In addition, it boasts an unusual talent; it can generate code in other programming languages.

In this talk I discuss the language’s killer features (and how I use them in GPU programming work), I explain the benefits of blending your static data with your code via haxe’s compile-time code generation, and I aim answer questions including:

"To make an apple pie from scratch, you must first invent the universe" - Carl Sagan

We’ll show how a Hello World program in C++ works from scratch, inventing the universe as we go along. We’ll demystify the journey your source code takes from textual representation to bytes executing on your processor. If you’ve ever wondered how the myriad of tools involved in translating and running C++ operate and fit together, then this talk is for you.

Topics covered will include stages of compilation, linkers, static/shared libaries, object file loading, operating system interaction, and maybe some apple pie.

If you have ever asked yourself the question "Why did they do THAT!?" when wrestling with a developer’s work, this session is for you.

My completed doctoral research does not answer it, but it does refine the question; I have built a definition of what “THAT!” is by interviewing software developers with a total of more than 400 years of industry experience between them. At ACCU 2014 I shared common themes that emerged: what experienced developers said about the day to day decisions made by their peers and how these make the job harder or easier. In this session I’ll give a brief recap.

These findings catalogue what constitutes “good practice” from the unique perspective of how it affects peers’ progress in their own tasks. But by itself, this catalogue does not change developer practice. In pursuit of helping developers to help each other to a better Developer eXperience, I have tested a workshop format that draws on the collective experience of the interviewees to allow teams to step back and reflect on their practice in a safe and encouraging environment. I will be explaining what these experimental workshops involved, why developers liked them and the potential the materials could have for other applications. You will have the opportunity to try the reflective workshop process for yourself.

Acknowledgement: My research would not have been possible without the generous help of my participants. My heartfelt thanks to all the software developers who volunteered to take part and the companies who allowed them to do so, and to ACCUConf for allowing me the opportunity to advertise for volunteers. I hope you all benefited from the experience.

A common pattern in multithreaded applications is the use of callbacks, continuations and task pipelines to divide the processing of data across threads. This has the benefit of ensuring that threads can quickly move on to further processing, and can minimize blocking waits, since tasks are only scheduled when there is work to be done.

The downside is that they can weave a tangled web of connections, and managing object lifetimes can now become complicated.

This presentation will look at ways of managing this complexity and ensuring that your code is as clear as possible, and there is no possibility of dangling references or leaked objects.

Most modern languages treat functions as first-class citizens, and Modern C++ is no different. The introduction of lambda expressions and utilities such as std::function enable countless functional programming patterns that can increase the flexibility and safety of APIs, and help reduce code repetition in the implementation.

In this talk we’re going to see examples of how higher-order functions can be used in practice to increase the quality of production code and the productivity of developers. A new abstraction I proposed to the Standard Library for C++20, function_ref, will also be covered and compared to other techniques for the implementation of higher-order functions. function_ref aims to be a lightweight wrapper over any Callable with a given signature that is easy for the compiler to optimize and inline.

std::tuple has been the source of many presentations over the years, as the library specification glosses over a variety of implementation pitfalls, while successive standards increase the complexity.

C++20 finally provides a number of features that, when combined, can yield a much simpler solution, saving developers of generic wrapper types from layers of expert-only code.

This talk will show how applying the new Concepts language feature, in conjunction with new attributes and some extended syntax, enable the delivery of an optimized high performance implementation that is almost as simple as just declaring a class with a few data members. No metaclasses required!

Concrete examples, based on real-world code, of how converting Java code to Kotlin improves it.

We will cover:

One of the joys of Kotlin is how easy it is to make a gradual transition from Java. All of the examples will demonstrate code that can be dropped in to an existing Java code base with little or no disruption.

If we have time, we’ll discuss things we wish were in Kotlin, and whether any of them are plausible on the JVM platform.

Many of us use Git to manage our source code every day, and rely on it to be fast, reliable and secure.

We are aware Git has a large number of powerful features, but often find it hard to remember how to use them. Instead, we rely on a small number of commands that get our work done day-to-day.

The key to unlocking Git’s most powerful features is understanding its underlying model.

In this session Andy will work with you to question CB mercilessly about how Git actually works, revealing the fundamental concepts that give it its power, and its - shall we say quirky? - interface.

This session will be guided by questions from the audience, but we hope and expect to explore areas like:

Learning to correctly use C++ is not difficult: teaching proper C++ usage is where the challenge lies, and at some point in your career, you’ll need to teach someone something about C++. You may not be a university lecturer or on-site trainer, but you could find yourself helping a colleague with their problem, presenting at a lunch-time session, or even at a conference! Perhaps you are someone who contributes to the company style guide or 'Intro to Our Repo' manual.

Correctly teaching C++ is a tough endeavour. C++ is underrepresented at the university level, and is often incorrectly taught both at a formal level (e.g. university, textbook, etc.) and an informal level (e.g. online tutorials, YouTube, etc.). Many resources are still outdated or refuse to change with the enormous paradigm shift that the C++ community has undergone over the past two decades.

We should seek to convey correct information and provide resources that stick with the facts. We should make learning C++ an enjoyable experience; and that stems from the way in which we teach it. In this talk, we will address how to:

This talk will present the current state of my work on designing and implementing Physical Units Library for C++. I will present all the challenges, design tradeoffs, and potential solutions to those problems. During the lecture, we will also see how new C++20 features help to make the library interface easier to use, maintain, and extend. Among others, we will see how we can benefit from class types provided as non-type template parameters, how new class template argument deduction rules simplify the interfaces, and a full power of using concepts to constrain template types.

Jupyter notebooks have rapidly become the de facto way to share data science projects on portals such as Kaggle. Jupyter is a great rich media prototyping and experimenting platform for Python and R but many people don’t realise that you can use it for far more.

This talk will be predominantly live demo and some limited slide presentation, introducing Jupyter notebooks, and the background to their more common use cases before finally diving into the Jupyter/Cling C++ interpreter to explore some of the impressive prototyping and exploratory potential of this powerful combination.

We will briefly look at the pre-requisites, and installation, some lightweight guidance on the Jupyter interface and then drop into some demonstrations

Not so long ago, not much happened in the world of DNS. Certainly nothing that was of much concern to the average developer.

At ACCU2017 I reported on the state of DNS 30 years after the publication of RFC1035, the RFC that defined the internet Domain Name System. At the time there were signs that some important changes were beginning to gather speed.

In the last two years, what was a trickle has become a flood. Support for DNS privacy in the form of DNS over TLS (DoT), preventing snooping on queries, has gathered steadily, and is the default in Android Pie. Then in October 2018 IETF unleashed RFC8484, DNS Queries over HTTPS (DoH) on a largely unprepared world. This is poised for very rapid adoption by the major browsers. In late October 2018, it’s already in Firefox, and is widely expected to land in Chrome soon. DoH probably marks a seismic change in how and where name resolution happens, the full consequences of which will only become apparent over time.

In this session, suitable for all-comers, we’ll take a run though how DNS is changing, and bring you bang up to date with the very latest DNS technologies. We’ll look at what the impact of DoH is likely to be on your systems, and cover what, as a developer, you need to know about these new toys, how you can use them, and where to go to find the information you need should you have to navigate the 2000+ pages of DNS RFCs out there and retain your sanity.

And we’ll meet the DNS Camel.

It doesn’t matter what language you use, what platform you code on, or what editor you prefer; there’s one underlying thread common to all code: people. It’s also the hardest part of coding. Unless you’re a team of one, writing code only you are going to use, people are always going to enter into the equation. So lets bypass the fancy algorithms, forget about the methodologies, and look at how we deal with the people aspect of code. The people we work with. The people we’re coding for. The people who were here before us. And the people that will come after us. And maybe, just maybe, we’ll come out of it better developers.

In 1999, NASA lost the $125 million Mars Climate Orbiter as it went into orbital insertion. Due to a mismatch between US customary and SI units of measurements in one of the APIs, the spacecraft came to close to the planet, passed through the upper atmosphere and disintegrated. Sadly, this hasn’t been the only instance where a mismatch between units of measurements had catastrophic consequences, but it’s certainly one of the most spectacular and expensive ones.

How could this happen? The bad news is: if you use primitive types to handle quantities in your code, due to that very same practice. At best, you’ve codified the unit in the name of the variable or the database field, e.g. calling it lengthInMetres. Otherwise, you’re only relying on convention, just like Lockheed Martin and NASA did.

Join this talk to learn how JSR-385 can help you avoid $125 million mistakes, and discover the immeasurable world of dimensions, units and quantities.

Traditionally, embedded applications are written in C. Using C++ is often frowned upon, because it is assumed to be less efficient. This talk shows how the interface of a typical embedded library can be made safer and more user-friendly, without being less efficient. Starting from a C-style interface modern C++ features are applied, like namespace, enum class, overloading, default argument values, std::byte, std::array<>, and templates.

This session will introduce attendees to Apache Milagro which enables a post-PKI internet and provides stronger Mobile and ioT security while offering independence from monolithic third-party trust authorities Milagro’s purpose is to provide a secure, free, and positive open source alternative to centralised and proprietary monolithic trust providers such as commercial certificate authorities and the certificate backed cryptosystems that rely on them. As use case we will show a fleet vehicle tracking application in C++14 and how the embedded parts will log into the system to provide real time vehicle status using Milagro Multi-Factor Authentication (Milagro-MFA).

The free-text format log file has been a staple technique for diagnosing systemic problems for decades and yet it has always served its masters poorly by being a victim of its own unstructured nature. Even just a little structure and an appreciation of the two competing narratives of operations and development can make a big difference to gaining an understanding about what’s really going on inside our systems. Modern tooling, which provides superior querying and visualisation today, is no panacea and still requires effort to compensate for their limitations.

This session looks at what techniques we can use to make monitoring of our systems, its dependencies, and its consumers easier and more comprehensible so that when the klaxon sounds we are better informed about where the problem may lie. And then, when resolved, how that knowledge is fed back into the backlog so the system can adapt to it in the future to help separate the signal from the noise.

Rust is a systems programming language from Mozilla that’s been around a few years now. In this talk I will give an update on the state of Embedded Rust, and illustrate the talk with "Monotron" - a toy 'home computer' with a ROM written in Embedded Rust.

Monotron started out because I found I missed the simplicity of of computers like the C64 and the Apple II. I wondered - can I recreate something like that, but using the Cortex M4 devboard on my desk and as few external parts as possible? Could I generate VGA without a video chip? Could I render text without enough RAM for a framebuffer? Could I read from a PS/2 keyboard? Could I generate audio, while doing video at the same time? Most importantly, could I do it all in Rust, and run unit tests on an proper PC? And would it run fast enough to be useful?

A practical talk with few slides, and lots of live demos of debugging tools and techniques that will make you a much more effective programmer.

As Kernighan says: everyone knows that debugging is twice as hard as writing a program in the first place. Debugging dominates software development, and is as important as it is overlooked. All too often we rely on printf or at best some basic gdb with not much more than 'breakpoint', 'continue', 'next' and 'print'.

This talk will demonstrate some of the power of newer versions of GDB (Reverse debug, dynamic printf, amazing scriptability with Python), as well as some of the other Linux debugging tools at your disposal: ftrace, strace, ltrace, valgrind, rr, asan, perf, and others.

The presentation works either as a stand-alone talk or as a follow on to Greg’s popular 'GDB Power User' talk at ACCU 2017.

When you write a library, you want people to use it. (Otherwise, why write it as a library?). But to attract and keep users, you need to provide more than "a bunch of code". In this talk, I’ll discuss some of those things.

I’ll talk about:

as well as tools that you can use for providing these things. Examples will be taken from Boost and libc++, the C++ standard library implementation for LLVM.

Nim is a statically typed systems and applications programming language which offers perhaps some of the most powerful metaprogramming capabilities. It is also the first language that is compiled to native executable code and fully supports runtime hot code-reloading without almost any limitations, along with a REPL - a language environment cherished especially by those working in science and education.

The session consists of a quick introduction to the language, followed by a demo of runtime hot code-reloading + the use of a REPL along with an explanation of how it all works. The approach is applicable to other compiled languages as well - even C/C++!

This is a hands-on demonstration of optimising a small real-world application written in C++.

It shows how measurement tools such as strace, perf tools, valgrind and cachegrind on Linux can be used to find the hotspots in an application. It also demonstrates some common pitfalls and how to avoid them by using different algorithms or libraries.

Design by Contract is a technique to clearly express which parts of a program has which responsibilities. In the case of bugs, contracts can mercilessly point a finger at the part that violated the contract.

Contracts are coming as a language feature in C++20. I will show how they can make your interfaces clearer with regards to use, but also point out pitfalls and oddities in how contracts are handled in C++.

Writing good contracts can be difficult. I intend to give you guidance in how to think when formulating contracts, and how to design your interfaces such that good contracts can be written, because contracts have effects on interface design.

Warning: Parts of the contents are personal opinion.

Python is growing in popularity, and as part of this it’s finding its way into more and more software development projects. In many cases, though, the introduction of Python is a bit ad hoc, with an automation script here and a data processing script there, with little thought towards engineering concerns like maintenance, distribution, or deployment. Over time, many teams find that their “little Python scripts” have grown into unmanageable – but critical – parts of their ecosystem. What can we do about this?

In this workshop, we’ll start from the premise that you already know some Python but you need to learn some engineering “best practices” for using it. The topics we’ll look at include:

You’ll start with a flawed-but-working body of code, and over a series of exercises you will turn it into a well-structured, shareable, manageable Python package. The lessons in this workshop are intended to be concrete, and you should be able to apply any or all of them to your Python projects.

Most modern systems require writing asynchronous non-blocking code - from the ordinary GUI applications which can perform time-consuming operations, but still be responsive to the user input; to servers that need to be able to process many requests at the same time. Most of the commonly used approaches to solve concurrency (such as event-loop based applications with event callbacks, or multi-threaded and distributed multi-process systems) have a big problem of having to handle and synchronize the state that is shared between different code paths that run concurrently.

To quote John Carmack: A large fraction of the flaws in software development are due to programmers not fully understanding all the possible states their code may execute in. In a multithreaded environment, the lack of understanding and the resulting problems are greatly amplified, almost to the point of panic if you are paying attention.

We are going to cover an emerging programming paradigm called Functional Reactive Programming (or FRP for short) which achieves concurrency using events-based programming. But, unlike the event-callback-based systems, it does so in a much cleaner way. This talk will be about the design and implementation of a reactive programming model inspired by ranges that allows easy implementation of asynchronous software systems by writing code that looks like a sequence of ordinary range transformations like filter, transform, etc.

This programming model will be demonstrated along with the implementation of a simple web service where the whole system logic is defined as a chain of range transformations.

“Regular” is not exactly a new concept (pun intended). If we reflect back on STL and its design principles, as best described by Alexander Stepanov in his 1998 “Fundamentals of Generic Programming” paper or his lecture on this topic, from 2002, we see that regular types naturally appear as necessary foundational concepts in programming. Why do we need to bother with such taxonomies ? Well, the STL now informally assumes such properties about the types it deals with and imposes such conceptual requirements for its data structures and algorithms to work properly. The new Concepts Lite proposal (hopefully part of C++20) is based on precisely defined foundational concepts such as Semiregular, Regular, EqualityComparable, DefaultConstructible, LessThanComparable (strict weak ordering), etc. Formal specification of concepts is an ongoing effort in the ISO C++ Committee and these STL library concepts requirements are being refined as part of Ranges TS proposal (<experimental/ranges/concepts>). Recent STL additions such as string_view, tuple, reference_wrapper, as well as new incoming types for C++20 like std::span raise new questions regarding values types, reference types and non-owning “borrow” types. Designing and implementing regular types is crucial in everyday programing, not just library design. Properly constraining types and function prototypes will result in intuitive usage; conversely, breaking subtle contracts for functions and algorithms will result in unexpected behavior for the caller. This talk will explore the relation between Regular types (and other concepts) and STL containers & algorithms with examples, common pitfalls and guidance.

C++ is a complex language and with the introduction of move semantics, noexcept and constexpr in C++11 and later, defining or declaring the right combination of magic keywords in the right place is daunting for the uninitiated. The talk will provide guidelines for how to circumvent expert territory and if needed, how to step there without shooting yourself in the foot or tripping a mine.

Many C++ guidelines try to limit the use of language features so that resulting code has higher chances to be correct and safe. This talk will give an overview of the kind of classes you can create in such a controlled setting and provides a map to where is expert territory that requires deliberate care about your classes.

For example, there is the Rule of Zero telling that you should let the compiler figure out what to provide. It carries far for the application level programmer, but still might not be sufficient. Should you then rely on the Rule of Five or Six? What would be the consequences? When should you actually deviate from the Rule of Zero and how?

Another area are classes representing values. Value classes better not have virtual member functions. But should you use final or not? Do you really need class hierarchies?

You will learn what kinds of classes are safe to design and how to spell their special member functions.

Security is an ever more important topic for system designers. As our world becomes digital, today’s safely-hidden back office system is tomorrow’s public API, open to anyone on the Internet with a hacking tool and time on their hands. So the days of hoping that security is someone else’s problem are over.

The security community has developed a well understood set of principles used to build systems that are secure (or at least securable) by design, but this topic often isn’t included in the training of software developers, assuming that it’s only relevant to security specialists. Then when principles are explained, they are often shrouded in the jargon of the security engineering community and so mainstream developers struggle to understand and apply them.

In this talk, we will introduce a set of ten key, proven, principles for designing secure systems, distilled from the wisdom of the security engineering community. We’ll explain each principle the context of mainstream system design, rather than in the specialised language of security engineering, explaining how it is applied in practice to improve security.

Since Bitcoin first rose to public awareness in the early 2010s, cryptocurrency enthusiasts have predicted a new world order. Central banks would fall away to be replaced with a consensus currency arising almost magically out of a worldwide network of independent computers, each transaction indelibly carved into the blockchain. The blockchain, immutable and permanent, stretching back in time to the genesis block, and growing, every few minutes, one block at a time, is, they say, the answer to all our economic ills.

And not just our economic ills: blockchains, perhaps running some kind of smart contract, have been proposed as solutions for insurance markets, music distribution, land registries, voting, distributed file archiving, provenance of artworks and antiques, domain name resolution, human resources records, cross-border customs clearance, and more.

In this session, we’ll have a look at what a blockchain is - how they’re implemented, and why they can indeed claim to be immutable. We’ll examine different consensus mechanisms, and how they allow new blocks to be formed without a central authority. That will lead into an overview of transaction mechanisms, and smart contracts. We might even write and a deploy a little smart contract of our own.

Alongside establishing a baseline understanding of what blockchains are, we’ll also be looking at why they’re terrible.

The distributed nature of public blockchains purports to allow us to trust data produced by unknown and, indeed, unknowable third parties. This may not be the case, and if it isn’t you might never know. Blockchains are permanent and immutable, but is this feature or misfeature? While the ideas behind blockchains are all frightfully clever, is a blockchain basically a database with slow reads, really slow writes, and generally awful data throughput? Are they, in fact, ill-suited for many of the applications they are pitched to solve? And if you thought multi-threaded programming was hard, that’s just peanuts compared to smart contracts. Maybe we’ll also get a bit existential and consider whether a blockchain can die, and what happens if it does.

After all that doom and gloom we’ll try to end on a small positive note, with a brief look at a project which I believe is a good fit for a blockchain solution, and which might even make the world a slightly better place.

Visualization leverages research on human visual perception. Its application in software engineering allows us to process information much quicker than in solely textual form. In this talk I will explain which laws for visually encoding/decoding information exist and how they are utilized by existing software visualizations to display different aspects of a software system. Then I will show how we applied this research to interactive source code navigation within Sourcetrail, a source explorer built on top of the LLVM/Clang LibTooling and Eclipse JDT Core libraries. The aim of this talk is to provide an overview of existing software visualization approaches and demonstrate their benefits and limits in day-to-day software development.

There’s many patterns we learn to recognise in software, good and bad - and increasingly, we expect our compilers to spot those in our development. But we can improve on that - modern compilers give us all the building blocks to add static checking specific to a particular API, framework or even project.

Automating these checks can increase code quality, simplify code reviews, and enforce many stylistic points: for example using a particular string encoding, or avoiding certain APIs. Here we present an example of such a tool: Clazy, a plugin for the Clang compiler, focused around the Qt libraries. Clazy extends the compiler with additional warnings and checks specific to Qt, making development easier and more robust. We will show how some checks are implemented, and how this technique could be applied to other large frameworks usefully.

Dynamic memory allocation is a feature that is often taken for granted. Most developers use some form of new or malloc every day, usually without worrying too much what goes on behind the scenes. But what about those situations where the built-in mechanisms are not good enough, be it for reasons of performance, safety, or due to restrictions of the target hardware?

In this talk we will explore how custom allocators can be used to overcome those issues. We will explain how basic allocation techniques like pooling and monotonic allocation behave with regards to performance and reliability. We will take a look at some of the technical challenges behind allocators, like the different forms of alignment and the way that the standard library manages stateful allocators. And finally we will take a look at some popular allocator implementations and how to integrate them with a modern C++ codebase.

The process of natural evolution has inspired programmers to develop machine learning algorithms that can ‘evolve’ solutions to problems. Such ‘evolutionary algorithms’ have been widely applied and to illustrate their use, we take the evolution of a solution to the counting game FizzBuzz as an example. (A typical game of FizzBuzz involves counting through a sequence of numbers starting at one, but multiples of three are substituted with ‘Fizz’, multiples of five are substituted with ‘Buzz’, and multiples of fifteen are substituted with ‘FizzBuzz’.)

This highly interactive programming workshop is aimed at programmers with reasonable competency in Java who wish to learn about evolutionary algorithms and implement them to solve FizzBuzz.

The workshop begins with a brief introduction on some of the biological processes of evolution and how they’ve shaped the approach of evolutionary algorithms. To get programming as quickly as possible, we use an evolutionary algorithm framework, the open source Java Class Library for Evolutionary Computing (JCLEC) (http://jclec.sourceforge.net).

Workshop participants are introduced to programming with the framework by exploring: (i) ‘OneMax’, a ‘hello world’-type kata example for evolutionary algorithms, (ii) ‘how to program you way out of a paper bag using genetic algorithms’, and then (iii) ‘FizzBuzz’, a counting game.

The workshop then explains Genetic Programming (GP), where source code expressed as Abstract Syntax Trees (ASTs) (or other grammars) can directly evolved with evolutionary algorithms. We also explain how Genetic Programming has been used for automatic bug fixing and the ‘genetic improvement’ of programs.

By the end of the workshop, participants will have gained a practical understanding of the components of evolutionary algorithms (e.g. solution representations, fitness measures, diversity preservation operators), and know how extend and implement them via a framework.

Participants are strongly encouraged to download and install the JCLEC framework before attending this programming workshop and bring their own laptop with a Java development environment installed.

Security vulnerabilities and secure coding is often talked about in the abstract by programmers, but rarely understood. In this talk we will walk through a simple exploit, how it’s developed and how it’s used. The goal is to try to get a feeling for the point of view of an "attacker", and to slowly start looking at exploitation as another programming tool. We will mainly be looking at C and x86_64 assembly, so bring snacks.

As a community we’ve tried many different ways to express, propagate and handle error conditions in our code over the years. Each seem to have different trade-offs, with none being perfect in all cases.

In C++ we adopted exceptions as the primary mechanism early on, and the standard library uses them extensively.

Yet many - 52% according to last year’s Standard C++ Foundation survey - ban exceptions in all, or part, of their codebases!

Recently there has been a lot of interest in using ADTs (Algebraic Data Types) such as std::optional, or the proposed std::expected, for error-handling. There are definitely advantages here, but we’re still not quite there yet. Can we do better?

This presentation summarises the material from my earlier talk, "Option(al) Is Not a Failure", where I survey existing error-handling approaches and score them against each other, leading up to the new proposal, p0709r1, "Zero-overhead deterministic exceptions". We then dig into this proposal in more depth and look at the implications, considering also the supporting proposals, p1028 (std::error) and p1029 ([[move relocates]]) and others. We’ll also look at experiences with similar mechanisms in other languages, notably Swift, to get an idea of how it might work out in practice.

In the end we should have a solid idea of which error handling strategy to use when, what’s coming next, and how to approach code now that will play nicely in that possible future.

Jai is a soon to be released programming language by famous game developer Jonathan Blow. The language focuses heavily on data oriented design, compile time functionality, and static reflection.

In this session, we will briefly go over the main features of Jai, their rationale, and what we can learn from them in order to improve our code and C++ as a language. Jai has been in development since 2014 and is intended to act as an alternative to C++ for game developers.

I believe that since then C++ has been moving in a similar direction to Jai and that there is a lot we can learn from Jai in order to improve C++. I have been following Jai since its inception and believe there is a lot of value in analysing it in order to improve C++.

Package management was considered one of the hottest and crucial topics in the last 2 years. In 2017, Bjarne Stroustrup himself said this was a something we needed to solve to keep students interested in C++.

Where do we stand today, in 2019? Join me for a tour of the topic, including:

"Blockchain is to transaction, what the Internet is to information." That sounds mighty, but what really is blockchain? What void does it fill, and how does it really work behind the scenes? This story styled talk will walk you through a world of many marbles, some blocks and a chain, slowly exploring the nuances of the technology, wading through cryptography, consensus protocols and mastering the intricacies of the technology.

They say silence can speak volumes. In a C++ application there are many places where not using a keyword or a piece of punctuation is a deliberate decision that carries a lot of information. Consider not marking a member function const, or virtual, or consider not indicating that a parameter is passed by reference. While in some cases this may be an oversight, a reliance on defaults that might or might not be appropriate, in others it’s a deliberate decision based on careful thought and design. How is a reader to know which is the case?

In this talk I will show some of the many places where nothingness carries meaning, and talk about approaches to increase the information others can get from your nothingness.

"It’s just semantics." How many conversations about philosophy, politics and programming are derailed by this thought-stopping comment?

Semantics is all about meaning. If there is one thing we struggle with and need to get better at, it is the search for and clarification of meaning. The world in which a software system lives is filled with meaning. The structure, concepts and names that inform the code, its changes and the mental models held by developers are expressions of meaning. The very act of development is an exercise in meaning — it’s discovery, its formulation, its communication. Paradigms, processes and practices are anchored in different ways of thinking about and arriving at meaning.

But just because we are immersed in concepts of meaning from an early age, and just because the daily work of software development is about wrangling meaning, and just because it’s just semantics, that doesn’t mean we’re necessarily good at it. It takes effort and insight. Let’s talk about what we mean.

Hash trees, or Merkle trees, proposed by Ralph C. Merkle in 1979, are binary trees where parent nodes are computed from child nodes using one-way hash functions.

Hash trees can be used to build efficient authenticated data structures where a response to a query about the structure comes with a proof that the response is correct.

The talk will give a quick introduction to hash functions and then go on to discuss hash trees and some of the authenticated data structures that can be built based on them.

This is an expanded version of the last year’s "quickie" talk on the same subject.

Many programmers are familiar with the Windows "Win32" API that provides access to a large variety of services, from user interface to memory management; but far fewer have much idea about the Windows "Native" API which is the mechanism used to access the operating system services located in the kernel.

While it is rare to need to use these services directly (since the Win32 API provides a richer, better supported, and documented interface) it can be very useful to have some understanding of what is going on 'under the covers' inside this API.

I will look at the Native API from the application programmer’s point of view and will also touch on how Microsoft provides a 32bit subsystem in the 64bit version of Windows.

I hope this session will be of interest to all those who like to know more about how things work!