ACCU 2017 Sessions

Clang - is the name of the C/C++ frontend in LLVM project. It has many powerful features and one of them is its design. It was written in a way that allows to use it inside any IDE as a provider for various things - from navigation and code completion to refactorings. But is it possible to use it with the modern Java IDE? That is the question we will answer in this session. Our team spent some time porting Clang into Java. We will tell you how it was done, what difficulties we faced and what outcome we have at this point.

Creating and maintaining a FOSS project is time consuming, but easy. Getting users and popularity, is a bit harder. Targeting C and C++ developers as users, in the developer tools (devtools) space, that is really tough. And if we are talking about creating the "missing link" of dev tools, a C and C++ package manager, it becomes "Mission: Impossible"

This talk will summarize my experience, from founding a venture capital backed startup called biicode, then closing it, to finally creating Conan, a FOSS project recently acquired by JFrog. I will try to offer my insights to some of the following questions, as well as any other the audience might have:

This talk will deep dive into the unknown parts of OSS development, more specifically in the space of devtools, and all the important lessons learnt in the process.

This talk is inspired by last Accu 2016 talk by A. Bryce "How I Went from C++ Programmer to Running My Own Software Product Company"

ES6 is (almost) the most recent version of the language most commonly known as Javascript. Its publication in 2015 was the first update to Javascript since 2009 and brought a number of pretty radical revisions to both language and library.

This session takes a look at some of the most significant features, the impact they have on the way we write Javascript, how we can start using them today, why we should, and a look forward to Javascript’s future evolution.

In this tutorial workshop, I’ll present an introduction to Chapel through a combination of short presentations and hands-on programming sessions (i.e., bring your laptop!).

Over the course of this workshop, you’ll be introduced to Chapel’s unique language features for tasking and data parallelism, as well as those for specifying locality and affinity to enable scalability on clusters, the cloud, and HPC systems. I’ll also provide a brief introduction to Chapel’s rich base language, designed to simplify serial programming as in modern scripting languages (e.g., Python) while preserving the performance and type safety properties of traditional languages like C and C++.

In the hands-on sessions, you’ll be free to explore Chapel features through a combination of prepared exercises and/or free-form programming – on your laptop and, with luck, even a modern Cray system.

The fine print: Chapel requires a C++ compiler, POSIX threads, and a UNIX-like environment. Thus, attendees with Linux/*nix, MacOS, or Windows 10 with the Linux bash shell will have the best results. Alternatives include ssh-ing into such a system, Docker, or Windows with Cygwin. In short, if you arrive with access to a system (local or remote) where you can do a 'make'-based compile of a C/C++ hello world, you should be good to go.

When it comes to writing tests we often live in the here-and-now and consequently end up producing "write-only" tests. This session looks at what we need to consider if we want to create tests that our future selves and teammates will find valuable instead of becoming another burden on top of delivering the feature itself.

If there is one place that we find it easy to take shortcuts it’s when writing tests. Whether we’re under the cosh or have an overly-optimistic view of our ability to write self-documenting code, instead of creating tests that support the production code and development process we can find ourselves producing WTFs (Weak Test Functions). The net effect is often a viscious cycle that disparages, instead of encourages us.

In the past I’ve tried many different ways to try and short-circuit the test writing process, but have only come up short every time. This session takes a look at why skimping on elements of the test structure, such as organisation, naming and scope only leads to pain and hardship in the long run. Along the way we’ll uncover the truth behind common folklore, such as only having one assertion per test.

With its history going back to the early days of programming, rich heritage, tons of legacy code mixed with modern language features and patterns, quickly evolving language standards, and a variety of tools in the environment, C++ can be tricky and easily enable hacks and inaccurate solutions if you don’t cook it right.

Developing language tools (and IDEs in particular) is a good litmus test for such problems. When a tool gets confused by some code or fails to provide the full intelligence it’s supposed to possess, doesn’t that mean that developers should also pay more attention and be more careful in the same situations? This talk is dedicated to bringing such situations to light and sharing lessons learned.

We’ll cover core language trickiness and peculiarities, including preprocessor and context-dependent parsing, and how the modern language standards can be helpful.

We’ll also look at some good practices that can help prevent shooting yourself in the leg with C++, and will reflect on C++ Code Guidelines.

We’ll analyze the tooling heritage as well, looking at the variety of build systems, compilers, debuggers, unit testing frameworks and package managers. Understanding the drawbacks of how they are integrated into language tools will give us insight into their limitations as well as into more accurate and error-free development in C++.

It is good every now and then to pause and take stock, and this applies to ACCU (https://accu.org) too. Hence the aim of this session is to discuss issues facing the ACCU in a relaxed and informal way. ACCU Committee Members will be on hand to participate in the conversation. We will seed the session with some topics including:

We are very interested to hear your concerns and ideas so please bring them along. Members and non-members are all welcome.

It has been said, to err is human, to really foul things up requires a computer [citation needed]. Given the long tradition of AI, which sometimes attempts to make a sentient being from hardware, or body parts (think Frankenstein’s monster), are humans unique, or is this dream possible? Or desirable?

Intelligence is also used to mean information the state or businesses gather on you; this is increasingly done by machine. We frequently have to prove who we are by stating Mother’s maiden names, passwords, even swiping fingerprints. Much of this is processed by machine, powered by algorithms. What if they don’t believe we are who we say we are?

There is more to intelligence than an algorithm. Your thoughts have a context; belief systems, experience, insight, thinking, learning. SciFi offers Asimov’s law of robots. Clearly first order logic isn’t enough. Obviously brute force isn’t intelligence. So what is? Do we need it to run on hardware? Conversely, could we exist in cyberspace without a body? Where will it end?

Making programs run as efficiently as possible is a popular topic in C++; it being a fairly low-level language, it is indeed particularly well suited to mapping algorithms to the architecture that evaluates them with minimal overhead. Making that mapping as optimized as possible is a vast domain, which this talk merely introduces by presenting an overview compiling various techniques, their reasoning, when they can be applied, and the challenges associated with generalizing them throughout your source code.

The first part of this talk will focus on understanding the architecture, from which we will deduce what properties code needs to satisfy in order to map efficiently to it, and will cover aspects such as NUMA, multi-core, superscalar execution, instruction pipelining, specialized processing units, caching behavior and branch prediction.

The second part of the talk will present actual programming techniques that can be used to make use of the previously introduced properties, among others: asynchronous programming, strength reduction, tiling, loop unrolling and pipelining, branch elimination, vectorization, mixed precision and specialized algorithms. For each of those we will discuss how C++ templates can help in generalizing and combining those techniques.

Finally we will take a look at some benchmarks to assess how useful those techniques ended up being on particular use cases.

Kotlin is a new programming language for the JVM (and JavaScript VM) by JetBrains. It is a statically typed language designed to include the most pragmatic features from Java, Groovy, C# and Scala. Kotlin is what Java 9 should have been in an ideal world.

This session is an overview of Kotlin features using code examples and comparison with other JVM languages. The idea is to move from compiling and running "hello world" to more advanced examples, encounter some Kotlin puzzlers along the way and finish with actual program written in Kotlin (most likely Snake game).

Target audience: software developers (with basic knowledge of Java/Groovy/Scala syntax).

Multithreading in C++ has been used successfully for many years prior to the introduction of C++ 11 to run programs on multi-core hardware. Then the C++ 11 Memory Model for multithreading was introduced with much debate as to its proper application. On the one hand some suggest not to bother with atomics and just use volatile if at all. On the other hand some might be happy to have everything guarded with mutexes. Either side may have been discouraged from looking deeper into the C++ 11 Memory Model, put off by its apparent complexity. The talk will focus on different options of “memory order” when using std::atomic. It’ll explain what the memory order is and what each of the options mean. We’ll take a look at the C++ memory model, sequencing of expressions and synchronization between threads. The talk sheds light on compiler optimizations and generated assembly, examines out-of-order execution in CPUs and possible cache communication between cores. In the end it should be clear what an atomic variable does apart from storing a value.

Almost every C/C++ programmer eventually runs into a situation when they have to write a lot of boilerplate code. Enum to string conversion (and vice versa), data serialization/deserialization, remoting proxy/stubs are the most common cases. There is a number of different techniques to reduce the effort to produce this kind of code, such as macros metaprogramming, templates metaprogramming, tricks with files inclusion, special DSL with converters and so on.

This talk introduces one such technique based on clang 3.9 front-end and its special 'libtooling' library. It describes an easy method to analyze the existing C++ sources and to produce another set of C++ sources for specified task (for instance, enum to string converters). Development of a clang-based tool "from scratch" is introduced, including command line options analysis, clang compiler invocation, AST investigation, result code generation, etc. Also, the method for custom tool integration into the CMake-based build system is presented. The talk is illustrated with simple examples, which can be useful for making your own custom clang-based tools. Write less code and enjoy!

Modern development environments and debuggers enable us to spend much of our time writing and reading source code. This makes the life of a developer much easier and most of the time we can reason about our program solely based on the source code itself.

However, from time to time we need to understand the layers beneath our high level language; for example when debugging a program or a crash.

What sense can we make of a page of assembly language code - and how do we find the most important information easily?

I’ll look at some typical use cases, mainly focussing on 64-bit C++ programs as these are relatively "close to the metal".

The intent is to help you in relating the assembly language view of a program to the lines of source code.

(No prior knowledge of assembler is required.)

Leading C++ experts propose the C++ Core Guidelines to foster better coding practices for C++ developers. The Core Guidelines build around safe coding practices without losing C++'s efficiency, such as using const deliberately or minimize the use of raw pointers. Many of the guidelines provide hints for enforcing the guideline and some even require or imply effective static analysis tooling to make them useful.

IFS (Institute for Software) has a long history of providing static analysis within an IDE and also suggesting transformation for improving code, such as, applying C++11’s initializers, instead of uninitialized or old-fashioned initialized variable declarations. While already addressing some areas covered by the Core Guidelines, we recently targeted many more of those explicitly and provide corresponding static analysis and quick-fix refactoring support to adjust existing C++ code toward following the core guidelines.

This talk will introduce the C++ Core Guidelines and demonstrate how you can modernize your code and improve its quality without losing performance through automated tooling built into Cevelop.

Topics covered:

The audience will get an overview of the C++ Core Guidelines. Using practical code examples improvements through application of the guidelines is demonstrated. Tools will be shown, that aid in detection of guideline violation and automatic repair to guideline-conforming code. Attending developers will be enabled to apply the Core Guidelines in the future to create or refactor to safer and more maintainable C++ code.

This is a fun session based loosely on the popular UK TV game show Countdown [1].

In the TV version, in each round, contestants have 30 seconds to find the longest word using only a small set of letters.

In this version, in each round, teams have ~7 minutes to write the smallest C++ program which includes a given set of tokens.

For example, the tokens in one round might be:

A winning program (53 characters long) might be:

Numbers are limited: minimum two people per team, maximum 12 teams.

Each team will need a laptop with wifi and a modern browser.

All programs will be written in the browser using a customized cyber-dojo [2] which will automatically tell you your program’s size, and your score.

NB Although scheduled in a conference room, this session will take place in the hotel bar – how else could it be a "pub quiz" if not held in a "pub".

[1] http://www.channel4.com/programmes/countdown

[2] http://cyber-dojo.org

C++17 is adding parallel overloads of most of the Standard Library algorithms. There is a TS for Concurrency in C++ already published, and a TS for Coroutines in C++ and a second TS for Concurrency in C++ in the works.

What does all this mean for programmers? How are they all related? How do coroutines help with parallelism?

This session will attempt to answer these questions and more. We will look at the implementation of parallel algorithms, and how continuations, coroutines and work-stealing fit together. We will also look at how this meshes with the Grand Unified Executors Proposal, and how you will be able to take advantage of all this as an application developer.

Contracts programming is based in the idea that any operation has a number of preconditions and postconditions. Different instantiations of this idea have been used in different programming languages (Eiffel, Ada2012, C#).

In this talk, I will briefly cover the general ideas behind contracts programming. Then I will provide details on how these ideas can be incorporated into C++. I will present also the latest updates on the C++ contracts proposal that is under discussion at the ISO C++ standards committee.

Additional note: The content of this talk will be influenced by the results of discussions at the March ISO C++ meeting where I will present the proposed wording of the feature.

For reference, please see the latest ISO C++ paper "A Contract Design" [http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0380r1.pdf]

C++ coroutines have not yet been standardised, but are available today in Visual Studio 2015 (coming soon to clang/llvm) in the form of the stackless coroutines/resumable functions [1] presented at CppCon2016 [2][3][4].

This session will look beyond the canonical examples of generators and asynchronous IO to see if coroutines can be leveraged in the pursuit of C++ DSLs to make concurrency easier to work with for humans - "Concurrency at Human Scale".

As of writing, the investigations and technology behind this talk are still evolving, so the outcome is not a foregone conclusion.

Other material, illustrating the search for inspiration on how to tackle these problems, may include:

A look at other systems for specifying, testing and reasoning about concurrency such as Leslie Lamport’s PlusCal/TLA+ [5] (see also [6]).

A look at the facilities for high level control flow manipulation afforded by other languages and runtime systems such as Racket’s first class continuations, continuation marks and prompts [7][8].

A look at other programming models for concurrency including Erlang’s actors (in the form of C++ Erlesque Actors [9]), Linda’s tuple spaces [10], and Syndicate’s coordinated concurrent proramming [11].

Level: Intermediate to expert

References:

[1] Gor Nishanov, Jim Radigan : Resumable Functions - N4402 https://isocpp.org/files/papers/N4402.pdf

[2] CppCon 2016: Jame McNellis - Introduction to C++ Coroutines https://www.youtube.com/watch?v=ZTqHjjm86Bw&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH&index=41

[3] CppCon 2016: Kenny Kerr & James McNellis “Embracing Standard C++ for the Windows Runtime" https://www.youtube.com/watch?v=v0SjumbIips&index=61&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

[4] CppCon 2016: Gor Nishanov “C++ Coroutines: Under the covers" https://www.youtube.com/watch?v=8C8NnE1Dg4A&index=87&list=PLHTh1InhhwT7J5jl4vAhO1WvGHUUFgUQH

[5] Leslie Lamport: The PlusCal Algorithm Language http://research.microsoft.com/en-us/um/people/lamport/tla/pluscal/

[6] ACCU 2016: Dominic Robinson : Test Driven Specification – A Gentle Introduction to TLA+ (finding concurrency bugs before you write code) https://accu.org/index.php/conferences/accu_conference_2016/accu2016_sessions#Test_Driven_Specification_%E2%80%93_A_Gentle_Introduction_to_TLA+_(finding_concurrency_bugs_before_you_write_code)

[7] Continuations in Racket https://docs.racket-lang.org/reference/cont/

[8] Mathew Flatt et al : Adding Delimited and Composable Control to a Production Programming Environment http://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf

[9] ACCU 2014: Dominic Robinson : Comfortable concurrency https://accu.org/index.php/conferences/accu_conference_2014/accu2014_sessions#comfortable_concurrency http://www.infoq.com/presentations/concurrency-models

[10] Nichlas Carriero and David Gelernter : Linda in Context http://www.inf.ed.ac.uk/teaching/courses/ppls/linda.pdf

[11] Tony Garnock-Jones and Matthias Felleisen : Coordinated Concurrent Programming in Syndicate https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjD7M_Fgs7QAhUHCMAKHR8uBucQFggaMAA&url=http%3A%2F%2Fwww.ccs.neu.edu%2Fhome%2Ftonyg%2Fmarketplace%2Fcoordinated-concurrent-programming-in-syndicate-20160111-1409.pdf&usg=AFQjCNGZN1pub5uMIq-Bek7eH7-EuooN4w&bvm=bv.139782543,d.d24

2017 sees the 30th anniversary of RFC1035, the RFC that defined the Internet Domain Name System (DNS). These days there can’t be many applications that don’t interact with a DNS nameserver at some point, and as proven by the recent Dyn DDoS attack, DNS is a critical part of Internet infrastructure.

However, the only change visible to most developers in recent years has been encouragement to switch from gethostbyname() to getaddrinfo(), so you might be forgiven for thinking that nothing much has changed in DNS in the last thirty years.

Not so. After a shaky start, crypto authenticated DNS, DNSSEC, is gaining traction, and there are some potentially important services defined on top of DNSSEC such as DANE, using DNSSEC as an alternative chain of trust to certificate authorities. There is also work in progress on DNS Privacy, or preventing snooping on DNS queries.

In this session, suitable for all-comers, we’ll begin with a look at how DNS works currently, and then go on to look at DNSSEC and other recent and in-progress developments. We’ll see how to sign your domain with DNSSEC, how to use DNSSEC and other new technologies in your application, and try to answer any questions you may ever have had about DNS.

Strings tend to be an under-appreciated but very important part in modern code. Whenever you deal with human input, your code probably has to deal with strings at some point. C++ and the STL have traditionally been lagging behind other languages and their standard libraries, especially scripting languages, in allowing rich operations on strings. But things have changed with recent standards: processing strings has become both attractive and fast.

In this talk I’ll talk about dealing with strings, while keeping performance in mind. Why is optimizing string access important? What about string encoding? What if strings are connected to other data structures? What makes string operations slow and how do I avoid that?

In the 2016 conference I did a 90 minute talk on the design and evolution of cyber-dojo. In this talk I provide an update on its further evolution, talking about (but not limited to) its

http://cyber-dojo.org is an open-source web-based application for hosting team-based coding dojos.

Whether we like it or not, most of the programs out there are not deterministic; making developers to take an effort and start thinking about determinism, is known to be difficult.

On the other hand, the case for deterministic programs is strong, with multiple benefits available for such programs. These benefits include such things as replay-based regression testing using production data, production post-mortem analysis (including both server-side and client-side), low-latency fault tolerance, and so on.

Such benefits become even more important for interactive distributed systems, where various race conditions tend to represent a lion share of those bugs which manage to slip into production.

Fortunately, there exists a very practical approach (which has succeeded for a rather large real-world project) that allows to make components of a distributed system deterministic.

The talk discusses benefits of deterministic components for distributed systems, different definitions of determinism from practical standpoint, and the way to implement deterministic components (very shortly - good old event-driven programs/ad-hoc FSMs/Reactors plus several tricks to make them deterministic).

Level: Intermediate/Expert

Documentation’s lack of popularity among programmers is at least partly due to time wasted on too much documentation, and producing docs the hard way. However, neglecting software documentation and technical writing skills holds us and our projects back. The solution is to improve basic skills, integrate documentation with modern software development methods, and learn about modern tools. Topics include:

This workshop teaches what to document, what not to, and how to produce documentation without the pain of traditional approaches. Attendees will learn to write and publish effective documentation with less effort, and develop a long-term skill. This benefits all software development teams, because good system documentation is a universal software requirement.

As most developers have experienced, code frequently calls into unreliable agents: databases, remote services and highly inefficient algorithms. The calls can timeout, throw exceptions or return invalid results. The industry has invested much time and money in devising software patterns that attempt to minimise the impact of these routine errors. We propose to record the execution history of such calls for the purpose of assessing the likelihood of a task completing successfully. Our system can decide to cancel a call that is likely to fail in order to save the resource of both the caller and the callee, generally improving system resilience. Additionally, the system validates the results returned from successful calls and provides a recourse mechanism for cancelled calls. We achieve this by introducing instrumentation that is simple to add to C++ code that provides cancelling logic, validation, and result normalization.

Fenwick tree (sometimes also called binary indexed tree, or BIT) is a data structure that deserves to be much more well known among software developers.

Invented by Peter M. Fenwick in 1994, it allows updating of elements in an array and computing sums of arbitrary contiguous blocks of the array, both in time proportional to the logarithm of the length of the array. The magic bit is that the tree lives in the same array and does not take any extra memory!

Originally designed to support frequency counting in arithmetic compression, another usage example is mapping between screen positions and row numbers in a table where row heights may change.

Because CMake is already over 15 years old, best practices have changed over time, in particular in the last 4 years. This talk will explore how to achieve some tasks using modern CMake idioms, as well as tooling and future directions.

C and C++ developers wishing to build code on multiple platforms will often rely on CMake to find dependencies and generate their build system.

The Internet is full of ways to write CMake code as it was common in 2006. However, CMake itself has moved on. A new set of APIs introduced in more-recent CMake versions aim for a conceptual consistency, simplicity and modularity in CMake code which was not previously possible.

CMake backward compatibility promises ensure that existing code continues to work, but as for C++, this form of ‘Modern CMake’ aims to simplify the developer experience, result in easier, more understandable and maintainable code, and establish future direction for how we use CMake.

This presentation will illustrate some differences and advantages between legacy approaches to CMake code and ‘Modern CMake’. After this presentation, the audience will be able to easily recognize legacy code and be able to make refactoring steps to improve the build system code.

C++11 gave us lambdas in the language for the first time (if you ignore boost::lambda) - so it’s a functional language now, right? There’s a bit more to functional programming than having first class function objects. I’d even argue we still don’t quite have that. But does that mean we can’t do functional programming in C++? Yes. No. Maybe…​

First we have to define what functional programming actually is - and it may not be quite what you think. Then we need to see what valuable ideas have come out of the functional approach to software design and which ones we can use in C++ to good effect.

In the end we’ll see that, while not strictly a functional programming language, we can get quite a long way with immutable data types, persistent data structures, atomic references, and - if you’re not watching carefully - we might even throw the M word in there!

Elm is a statically-typed functional language designed for building reliable web applications with “great performance and no runtime exceptions”. Elm compiles to Javascript, is easy to embed into existing websites, and has great Javascript interop, meaning that you can use as little or as much Elm as you want in your project. In this talk I’ll introduce the audience to Elm, look at its syntax and tooling, and show where it fits into the larger picture of web development. I’ll also discuss the prescribed method for structuring programs built in Elm, “The Elm Architecture”.

Elm has a great community and excellent documentation, so my goal with this talk isn’t to give a comprehensive lecture on the language. Instead, I want to get you excited about the possibilities of Elm, maybe pique your interest in functional languages, and ultimately get you pointed in the right direction so that you can confidently start to explore Elm for yourself.

You’ve written a function that takes an integer and returns true if that number is a multiple of both 3 and 5. How will you test it? You could throw every integer at it, but that might take some time…​

Property Based Testing has become increasingly popular of late. It’s a form of parameterized unit-testing that automatically generates sample inputs to a test to try and dis-prove that test’s assumptions.

It grew up in the Functional Programming world (Haskell, specifically) but there’s more to it than Functional 'chic'. With adaptations in many languages and styles, and integration with a plethora of popular testing frameworks, programmers of all kinds are finding Property Based Testing a useful addition to their arsenal.

For a bit of fun, in this talk I will look at some simple problems that lend themselves to being tested this way, rather than, for example, by example-based testing. And since it’s enlightening to compare and contrast styles and languages, I’ll try and cover some different ones of those, including C++, C#, F#, Python, Ruby, maybe some Scala, perhaps even a little Powershell.

No prior experience is required, but some exposure to automated testing in one or more languages will be helpful. Open to all.

Your chance to put questions to a selection of members of the ISO C++ committee. Here are a few ideas:

It is unusual to find software which does not have to perform I/O of some kind, be it talking to persistent storage devices or communicating between networked machines. These operations are typically categorised by the fact that they incur latency - time which your software must wait patiently before it can continue its work. In a world ever reliant on distributed computing, with trends such as "cloud" and "micro-services", this concern has never been more prevalent. Developing software which is correct and resource efficient is not an easy task at the best of times, so involving slow networks and flaky spindles of rust will not make our life easier. Software which is heavily reliant on I/O is often complex in nature, as we encounter a number of trade-offs to achieve the perfect balance of efficiency, correctness and maintainability.

Is there finally light at the end of the tunnel? Patterns are now gaining acceptance in younger languages which are gaining a broad, cross-language acceptance not often seen. This talk will take a brief look at the history of writing I/O centric software, and the techniques employed over time. By understanding these and the reason for each evolution, we can be better equipped to write, test and debug asynchronous software. Whilst C and C++ will serve as a basis for most of the talk, emphasis will also be placed on language independent concepts where appropriate.

Topics to be covered will include:

Given time, the talk will briefly summarise techniques which have been employed in other languages, are not trivially available, or have lacked wide adoption in C/C++, such as: communicating sequential processes (Occam, Go), user-space (green) threads, task-stealing. We may discover that through all the techniques discussed, there is a lot more in common between them than is obvious at first glance.

Presentations in meetings have a tendency to be long-winding, telling you things you already know, things you don’t need to know, and things you don’t need to know yet. The things you actually need to know are in there, too; somewhere. But it’s hard to find them.

Wouldn’t it be great if business presentations were more focussed on the actual needs of their audience? And if they would only take 15 minutes, including the time for Q&A? Not possible? Well, presentation expert Joey Asher promises that it is possible. We’ll take a look at his approach and maybe you’ll only be giving 15-minute presentations from now on, too.

Note: This session is not a workshop but does have some interactive elements.

It sounds too difficult for mere mortals, but in principle a programming language interpreter is a relatively simple program. To demonstrate the main ideas involved, I wrote a very simple programming language called Cell (github.com/andybalaam/cell) and in this session we will walk through how it works.

Cell’s interpreter is written in Python, and the Cell language itself is designed to be as simple as possible to implement. This leads to some different trade-offs from most other languages, but hopefully leaves the main concepts intact.

We will walk through the code of Cell’s lexer (40 lines), parser (81 lines) and evaluator (92 lines) and on the way cover the main ideas you need to write your own language, including detecting the different symbols and literals the programmer wrote, building them up into a tree structure, evaluating the logic that is being represented, and writing a standard library of basic functions and structures.

This session is suitable for someone who has never thought of writing a programming language before. We will assume a working knowledge of Python code in places, but it should be simple enough to follow for anyone who regularly writes code in any language.

The addition of std::variant to the upcoming C++17 standard will introduce a "type-safe sum type" to the STL. Given a set of types, std::variant (and boost::variant) model an ADT ("algebraic data type") where only one of them can be active: they essentially are a type-safe "tagged union".

The interface they provide, however, is more cumbersome than it needs to be and doesn’t lend itself to monadic composition. Defining exhaustive visitors requires the user to create a class with several operator() overloads, or to create a chain of if constexpr(…​) calls. Both solutions are not very elegant.

After a brief overview of std::variant and its usefulness, this talk will focus on the implementation of a "lambda-based in-place visitation" approach, where the user can visit a variant by simply providing a set of overloaded lambdas on the spot.

Don’t be fooled, though - the implementation will not be as simple as it sounds. The talk will cover:

This talk is intended for an audience familiar with C++11 and C++14 core language features.

We often use the metaphor of smell to describe issues with code which haven’t necessarily manifested, but could end up causing serious problems (“code smells”).

Architectural and habitability smells can help guide us during low-level debugging. The goal of this session is to give participants the tools they need to help refine their own and others’ sense of code smell further.

Parallels will be drawn between techniques for refining actual sense of smell and improving debugging techniques.

First 40 minutes - theoretical overview

Next 40 minutes - mob programming practical

Fun, real-world problem with a custom threading implementation. There will be no libraries involved here - a complete (albeit small) scheduler / RTOS will be provided that isn’t quite working correctly.

The group will be split into “mob teams” of 4-5 people and set up next to a large monitor each (which I will provide) so they can "mob program” together in order to solve the problem. Mob programming is a relatively new Agile technique which we regularly use to solve difficult problems. Each person in the team takes in turns to “drive” at the keyboard.

There will be prizes for the winning team.

Test Driven Development (TDD) and Behaviour Driven Development (BDD) are very similar.

I’ll explain why the most important part of both acronyms is the first 'D' for Driven and why it would be better if the second 'D' stood for Design.

We’ll explore what challenges you might face when trying to adopt this way of working and what benefits you will reap when you succeed.

Since the introduction of the Bitcoin crypto currency by Satoshi Nakamoto in 2008, there has been an explosion of interest in the adoption and use of blockchain, the fundamental technology underlying Bitcoin (and its many variants). At Mosaic Financial Markets we have been researching ways of understanding and applying blockchain technology, focussing primarily (but not exclusively) on the Ethereum blockchain, as Ethereum offers a fully programmable 'smart contract' capability.

There is an enormous amount of interest (and hype) surrounding blockchains - we will explain what we have discovered, cut though some of the hype, and we hope give you some suggestions for working with this technology.

We have found that to successfully build blockchain applications, we needed to change the way we were thinking about the application architecture, understanding the benefits and costs of using a globally distributed, trustless, resilient and immutable transaction record.

This session will give you an overview of the fundamental concepts behind blockchains, including Bitcoin and its variants, Ethereum, R3’s Corda and other platforms under development. We will explain how we have lived with a rapidly-evolving platform which has undergone significant disruptive events, including the (in)famous 'DAO hack'. We have built three proof-of-concept Ethereum applications to help us understand what does and doesn’t work, and we will show you how and why we built them.

An introduction to Intel Security Guard Extensions which is a new hardware security feature allowing encrypting running code and data in RAM.

Applications wanting to include 3D graphics have mostly had to rely on low level graphics APIs or on a number of higher level scene graph based libraries. Modern day 3D graphics however has increased in complexity and many of the existing C++ libraries have struggled to provide versatility and performance. This is likely to become even more problematic with the growth of Virtual Reality and Augmented Reality.

Qt 5.7 introduces Qt3D, a new library for integrating 3D real time rendering in C++ application. Qt 3D is structured around an Entity Component System (ECS) architecture which will be introduced. We will present how to add custom geometries and materials to your scene, or how to deal with user’s input.

Furthermore, we will show how the ECS architecture has been used in two useful ways. First, data related to entities and components can be very easily be modelled in a declarative language like QML (which has been key to Qt’s recent development), enabling unprecedented ease of use for complex rendering techniques. Second, the separation of data and operations has facilitated the creation of a highly concurrent simulation engine, enabling the integration of many different algorithms.

This talk will be interesting to any developer having to implement a 3D scene inside an application (whether already using Qt, or evaluating various technologies for this job). No prior knowledge of OpenGL or GPU programming is required for this talk.

High-Frequency Trading (HFT) and low-latency trading are becoming one of the few preserves of C++. The fact that it is amenable to extensive optimisation, including micro-optimisations, has made it highly effective, some of the major trading systems are hybrid FGPA/C++ solutions or native C++ solutions.

By popular demand this talk will be an expanded and updated version of that given to ACCU/London! I shall provide an analysis of some micro-optimisation techniques that have been successfully used, but also an investigation of the pitfalls that may arise. For example: Performance anomalies lead to a discovery of quirks in generated assembler due to different compiler versions. Exactly what is static branch-prediction, and how is it (ab)used? Why is counting the number of set bits of the remotest interest? And the "curious case of the switch-statement" will be investigated. How fast can one create a FIX message (involving adventures in std::memcpy!)?

The complexity of the C++ language, which allows for versatility and good performance in a range of different domains, results in a steep learning curve and a reputation for being hard to learn and master. The rapid development of C++ with the recent standards C++11, C++14 and C++17 brings a challenge. What is modern C++, how can we keep up, and how can we avoid to learn and teach outdated idioms? The session discusses these challenges and then analyses the different information resources at our disposal, like books and different kinds of online content.

Are memory allocators worth the trouble? What situations merit their use? How are they applied effectively? What’s the performance impact? This practical talk by large-scale C++ expert John Lakos demonstrates that having local memory allocators in your tool box may lead to as much as order-of-magnitude speed improvements.

The runtime implications of the physical location of allocated memory are sometimes overlooked—even in the most performance-critical code. In this talk, we will examine how the performance of long-running systems can degrade when using just one global allocator (e.g., via new/delete). We will contrast the use of global allocators with various kinds of local allocators—allocators that allocate memory for a well-defined subset of objects in the system. We will also demonstrate how local allocators can reduce, if not entirely prevent, degradation seen in systems that rely solely on the global allocator. Six dimensions—fragmentability, allocation density, variation, utilization, locality, and contention—will be introduced to help characterize a given subsystem, assess the potential for accelerating its runtime performance, and—where appropriate—aid in determining the best local allocator to do so. Empirical evidence will be presented to demonstrate that introducing an appropriate local allocator can often result in substantial reductions in run times (compared with a similar system relying solely on just a single, global allocator).

Lock-free programming is an important technique for writing thread-safe code for low-latency and real-time applications. It is also often regarded as challenging and notoriously hard to get right. But it doesn’t always have to be that way! This talk gives an accessible but comprehensive introduction to the subject.

A lot of material has been published on lock-free programming already. However, the modern C++ standard has significantly improved the situation by introducing an inherently thread-safe generic type – std::atomic – and a well-defined memory model for multithreaded code. It is therefore worth approaching the topic of lock-free programming from the perspective of modern standard C++. In fact, all code examples in this talk will be standard-conforming, portable C++11/14, and we won’t discuss platform-specific solutions.

The talk will start by motivating lock-free programming and its use cases. I will then clarify the meaning of terms like atomic, lock-free, and wait-free. Diving into some actual code, we will discuss the usage of std::atomic, its member functions, its template specialisations, compare-exchange operations, and common pitfalls.

In the main part of the talk, I will then show various common use-cases of lock-free programming. We will discuss useful and generic ways to safely share and move data across threads without locks and critical sections. We will also work through the implementation of a lock-free data structure: the lock-free queue (also known as fifo or ring buffer). This will serve as an example of how lock-free structures work, when they’re useful, and what to watch out for.

This presentation is a case study taken from the travel and holiday industry. Paxport/Multicom, based in UK and Sweden, have recently adopted a recommendation system for holiday accommodation bookings. Machine learning techniques such as Collaborative Filtering have been applied using Python (3.5.1), with Jupyter (4.0.6) as the main framework. Data scale and sparsity present significant challenges in the case study, and so the effectiveness of various techniques are described as well as the performance of Python-based libraries such as Python Data Analysis Library (Pandas), and Scikit-learn (built on NumPy, SciPy and matplotlib). The presentation is suitable for all levels of programmers.

The index has been a core part of Git since its inception and yet its existence and purpose are often stumbling blocks for newcomers to Git. Even people experienced with Git often struggle to separate its interface from its implementation details.

This talk aims to improve understanding of the index and to show how to take advantage of its power.

First, we’ll examine the history of Git’s index - effectively the first feature ever added to Git - to help explain why the index is the way it is. I shall look at the background and rationale behind some of the other words used for index: "cache" and "staging area".

Next, I want to examine the features of the index as it exists in Git today and to separate exactly what I think that all Git users need to understand from the benefits that the index brings to Git’s implementation which aren’t necessary for a Git beginner to be aware of.

Finally, I’ll demonstrate some index manipulation tips and trips that have practical use. These will include a look at cases where the plumbing commands such as read-tree, update-index and checkout-index can be usefully employed, use of an alternate index by defining GIT_INDEX_FILE and the performance benefits of filter-branch’s --index-filter over more mundane alternatives.

In most languages, metaprogramming is a powerful tool that allows writing more expressive and more maintainable code. It is usually relatively straightforward, and even average Joe programmers can use it to increase their productivity. In C++, metaprogramming is an obscure art that very few understand and that is never taught as part of the normal curriculum. Even worse is the fact that almost every presentation about metaprogramming is overly complicated, using tricky corners of the language and an unintuitive approach to achieve even simple goals. This presentation will try to break the mold and present metaprogramming in a way that’s easy to grasp. Using C++14 and the Boost.Hana library, we will show how metaprogramming can be done with a reasonably high level of expressiveness, leaving dirty template tricks far behind. We will see how metaprogramming can be used as a tool for making day-to-day programming easier, more enjoyable and more efficient, even for people that are not C++ gurus.

For many functions which iterate over elements of a node-based container (such as std::list and std::map), the bottleneck is frequently due to accessing data from memory while chasing pointers. In bidirectional containers, these functions may be rewritten to reduce the number of data dependencies, thereby allowing modern processors to perform more operations in parallel.

In this session we will rewrite a few methods of std::list to demonstrate some of these techniques and benchmark them against current standard library implementations.

Many of the concepts presented in Andrei Alexandrescu’s book "Modern C++ Design" were arguably ahead of their time. Many of the concepts could not be effectively or cleanly expressed due to a lack of language features and the user was often exposed to too much complexity.

Now 15 years later we have many more tools. Now Alexandrescu’s as well as similar statically linking yet powerful and generic design patterns are proving invaluable in resource constrained and low latency fields.

In this talk I will share my experience creating "post modern" C++ abstractions for bare metal hard realtime systems as well as my work on the tools needed to provide sleek and sexy public interfaces for these libraries such as various improvements to template metaprogramming libraries, lazy evaluation techniques and named parameters.

I hope to add idioms and design patterns to any advanced programmers toolbox allowing them to more efficiently and more effectively abstract whatever domain they work in.

Are you using enums to return error states from functions (or even an int or bool!)? Do you find writing exception safe C++ a poor return on coding investment, and end up avoiding using most of the STL entirely because it could throw exceptions in all sorts of unhelpful places? Have you ever wondered what on earth the C++ 11’s <system_error> header is actually useful for?

One might think that after thirty years C++ would have decided upon a canonical way of handling errors, but it is very clear the jury remains out with heavy fragmentation in the C++ user base as to how best to handle errors. The new systems programming languages Rust and Swift have chosen a canonical error handling system based on immediate stack unwinding returns of integer error codes in a monadic wrapper e.g. Rust’s Result<T> and Option<T>. Efforts are underway to standardise something similar for C++ with optional<T> and soon WG21 LEWG’s expected<T, E> which recently lost its monadic operations as it gets pared ever further down to its essentials for standardisation.

This talk reviews these four standardised error handling techniques in C++, and how well the three major compilers and library implementations implement these techniques into overhead. I will also be introducing for the first time my own solution to this problem called outcomes (implemented by a proposed Boost.Outcome library) which implement a very impure and dirty - but very lightweight on compile and runtime overhead – simple “mongrel monad” outcome<T>, result<T> and option<T> transport factory specifically targeted at extending C++ 11’s std::exception_ptr and std::error_code in a more convenient to use form, thus providing a unified lossless error handling system for C++. I am hoping these will eventually form part of SG14 (games/low latency)’s recommendations for maximum performance C++ as a lighter weight and more convenient to use for error handling alternative to the LEWG expected<T, E>.

C++17 is the next evolution in modern C++ programming. Although it is not as big a step as C++11, it contains a large number of small and valuable language and library features, which will change the way we program in C++.

This one-day tutorial presents all the new language and library features in C++17. We’ll cover the motivation and context of each new feature with examples and background information. We’ll focus on how these features impact day-to-day programming and how to benefit from them in practice.

Contents:

The only boost.parameter library was seldom used, mainly because it is macro hell getting it working, its not SFINAE friendly and the return type of a function cannot depend on the types of the inputs. With modern C++ we can solve all those problems elegantly. This works especially well when making factory functions which spit out policy based class specializations.

C++ has seen a fast paced evolution over the last six years, giving performance oriented programmers access to high level features such as range based loops, automatic type deduction, lambdas and unprecedented compile time expressivity. The core guidelines has emerged as a manual for using the new language features to write type safe code without sacrificing performance or control. But the moment you want to interact directly with the operating system, to get block level access to a hard drive, interact with the file system directly, create a timer or set up a TCP server, it’s a blast from the past with good old POSIX. Brimming with macro magic, pointer / size- and even pointer-to-pointer interfaces and a very unnecessary amount of blocking calls, it’s obvious that a modern C++ implementation of the same functionality can be done much better, cleaner and safer. In IncludeOS we’re working on just that - we’re implementing POSIX because we realize there’s no way around it, but we’ve decided to create a modern C++ interface for every new feature first, and then wrap the old interface around that as an optional layer. In this talk we’ll show you our take on the virtual file system (mount a lambda or a const float safely on any file system path!), why integer-based file descriptors are all wrong, how we approach sockets, threading, asynchronicity and more.

C++17 introduces parallel versions of the algorithms into the standard C++ library. The algorithms are intended for the general software development community rather than addressing a few specialists. It is becoming more important for all developers to understand how the parallel algorithms can be used.

Different kinds of parallelism are exposed using corresponding execution policies. Each execution policy implies specific constraints for the use of algorithms to enable the respective parallel approaches. The interface for execution policies is described together with the constraints of the defined execution policies.

This presentation discusses the model behind the parallel algorithms and the associated constraints. Some example uses are shown together with results to motivate the importance of enabling parallelism in programs.

The current specification is an initial version exposing parallel interfaces and there are some proposals on refining the interface for better support of composition. The direction for making the parallel algorithms asynchronous is described together with some alternatives of how it can be designed.

Love them or loathe them, passwords are here for the foreseeable future so we really should learn how to deal with them properly. So much of what we think we know about passwords is based on historical half truths, and actually makes how we generally handle them less secure.

In this session we’ll look at how to safely, securely and quickly store passwords for login, and take a look at what implementation details you could be leaking by making people jump through hoops to generate a "valid" password.

Aimed at all levels from the absolute novice, to the advanced developer who may have picked up some bad habits, this light hearted, language agnostic talk will look at a simple problem that we persist in making hard for ourselves.

Collective Code Ownership is a tenet in most Agile methodologies and many Agile books suggest enforcing this with Pair Programming. Collective Code Ownership can also be upheld through Code Reviews. Formal code reviews can be very costly and destructive. They are hard to implement correctly but when done right they can provide many benefits such as finding bugs and sharing knowledge about designs and code base within the team. This talk looks at how to perform effective code reviews with little effort using code review tools to achieve the same benefits as formal reviews. I will share experiences with code review tools and compare a few available tools.

Job ads often ask for creativity as one of the skills for software developers. But what does creativity in software development actually mean? And how can you be creative under pressure?

This talk introduces a simple method to help you trigger your creativity when under stress.

Coroutines are an old idea undergoing a resurgence in popularity as they facilitate highly concurrent applications without recourse to the complications and intricacies of threads and locks. After many years of third-party support for coroutine-based concurrency in Python, the popular Python language has recently introduced first-class support with many new language features together with a supporting standard library called asyncio.

Coroutines are threads-of-execution implemented via resumable functions which, when combined with a suitable scheduler, can be used to support concurrency in the style of cooperative multitasking which can be simpler to reason about, and easier to debug, than the alternatives.

In the first part of this session we demonstrate the simplicity and essential qualities of coroutine-based concurrency by building a simple concurrency framework from scratch, in Python 3. This efficiently removes any notion that there is any hidden magic in how coroutines work in practice. We then, by a series of simple, mechanical transformations, convert our home-grown example into real Python 3 code using the recently introduced async and await language features, together with the asyncio library. In the final part of the talk we explore some of the abstractions Python 3 builds on top of coroutines such as futures, tasks, transports and asynchronous streams, and demonstrate how to use these in a practical application.

This session can serve as an introduction to coroutine-based concurrency for those new to the idea irrespective of programming language, and window into how asynchronous programming in Python works in theory and in practice. Around 80% of the session is code and live demonstration, with 20% supporting material.

Automated tests and executable specifications can only work with software that has a testable architecture.

A testable architecture enables fast and reliable tests that are easy to write, execute and maintain. Many organisations have the opposite – slow and unreliable tests that are difficult to write and expensive to maintain.

During this workshop, we will teach you how to decouple your domain logic from your infrastructure so that you can test at different levels, with maximum confidence and minimum cost.

You will learn advanced techniques such as ports and adapters (hexagonal architecture), contract testing and test pyramid – all essential for a testable architecture.

You will learn how these techniques are generally applicable, irrespective of the specific software architecture you are using.

The practical work will be carried out using Cyber-Dojo, an online training environment – all that is needed is access to a modern web browser. Delegates will work in pairs, so not everyone will need to bring their own laptop. The training material will be available in C++, C# and Java.

Learning Outcomes:

If you want to get best performance on today’s hardware, and you are not just working with the GPGPUs, using the multiple cores of the (possibly multiple) CPU is effectively mandatory. Thus for best performance software you have to write concurrent (and parallel) code. But writing concurrent code is hard. Writing concurrent code that is correct and has minimal contention is even harder.

In this hands-on tutorial we will see how to utilise available CPU cores efficiently in a simple way by using higher level abstractions like futures and CSP channels, instead of manually managing threads and using other low level synchronization primitives such as atomics and mutexes.

We will not dive into lock free data structures, sequential consistency, or ABA problems, etc. Instead, after laying some theoretical foundations, we will start with simpler problems, advance to complex use cases and then move on to abstraction techniques to write safe, readable, and fast code. You are encouraged to bring problems from your domain so that we can together discuss them.

The content of the tutorial is a follow up on Sean Parent’s concurrency talks in his series of goals for better code. We will utilize an open source library that he and I have developed.

You will need to bring a laptop with these minimal requirements: a recent C++14 compliant compiler (clang 3.7, gcc 6.1, or Visual Studio 2015 Update 3), boost 1.60.0 and cmake 3.5.1.

Programming language designers have to date largely failed the large-scale parallel computing community, and arguably even parallel programmers targeting desktops or modest-scale clusters. Parallel features are typically an afterthought in language design, tacked on as pragmas, libraries, or extensions. Even when languages are designed to support parallelism, they generally fail to consider distributed-memory computing. Other approaches tend to be domain-specific and not suited for more general parallel programming. Meanwhile, though the High Performance Computing (HPC) community has pursued many novel parallel languages, none have succeeded in getting over the tipping point of broad adoption.

Chapel is my team’s effort to reverse these trends. It’s a general-purpose language in which scalable parallel programming has been a motivating theme from day one. It’s designed with productivity in mind in order to make parallel programming less arcane and more modern in style. It’s portable and open-source in order to support a broad community and reduce barriers to adoption. And yet, like any new language design being undertaken by a modest-sized team, it’s not without its challenges – both technical and social.

In this talk, I’ll provide an introduction to Chapel’s motivating themes and features to give you a sense of what we are doing and why. I’ll also provide a glimpse into some of the challenges we wrestle with and how we are dealing with them. Whether you leave the talk a convert to Chapel or simply intrigued, I hope to challenge you to think about scalable parallelism as the first-class language feature that it deserves to be.

C++ programmers want fast and small code that is safe, generic and reusable. This talk shows how using the C++ type system and templates can achieve this using simple lightweight abstractions.

Type-rich APIs help avoid errors whilst improving readability, and template techniques provide reusable libraries for operators and their relationships with zero run-time overhead.

Hidden in the Library fundamentals Technical Specification, there is a section called "Detection idiom". The specification doesn’t really say what it is for, and it has not received a lot of notice.

That’s a shame. This is an amazingly powerful method for distinguishing between kinds of types. Writing SFINAE constraints is tedious and confusing, and this will make them much easier to do.

This session will introduce the detection idiom, talk about how it works, and then give examples on how to use it.

A basic knowledge of template meta-programming will be useful

As Uncle Bob pointed out, software is everywhere, and without software, nothing works.

That gives us great power, and – as we all know – with great power comes great responsibility.

We have to make choices every day that affect others, sometimes in subtle and non-intuitive ways. To mention just a few:

I hope to raise a few of these questions, not to provide answers – I don’t have any – but to stimulate debate.

I’m a developer and I get frustrated when things are harder than they should be. Our product (Mir) was harder to release and to use than it should be but no-one cared enough to do anything about it.

My employer allows time for (approved) "side projects". Exploiting this, I started writing an "Abstraction Layer" (MirAL) as a proof-of-concept that these problems could be solved.

Over time it became apparent that this approach solved other problems and management interest grew. Until MirAL became my "day job" and adopted as part of the product.

This talk covers the both the technical and organisational aspects of the problem and the solution. Hopefully, comparisons can be made with the experience of attendees.

Many programmers aspire to start a company. It’s less often about getting rich as it is to pursue a vision for a computer program(s) that is much bigger than one person could do alone. Like most programmers who start up, I had no formal training and little experience outside of software development. I was naively confident, and didn’t know what I didn’t know (it turned out that that was a LOT!) In this talk I’ll present some of the lessons I’ve learned along the way, many of which were a complete surprise to me. I’ll cover getting investment, building the product, building a team, and getting and keeping customers. Little of this talk is directly about programming, but it is aimed at programmers who want to create code in order to create a business, or who want to create a business so that they can create the code they want. This talk contains candid, warts-and-all war-stories, and because it’s for programmers, comes with a no adverts and no business-talk BS guarantee. Some of the content of this talk is also useful to programmers who are moving into management or customer-facing roles.

To most of us the linker is a tool that combines the output of many compilations into a single output file, but to many its inner workings are a mystery.

In this session we’ll deconstruct the linking process to reveal:

We’ll be concentrating on the ELF object file format, using the System V dynamic linking conventions. The details of linking on Windows are different, but the underlying concepts are similar.

The talk is suitable for intermediate developers with a working knowledge of C, ideally on a Unix like system. No prior knowledge of linkers is assumed.

Test Driven Development, Continuous Integration (CI), and testing with elastic compute in the cloud mean that a typical software project today will run 1000s of times more tests every hour than an equivalent sized project would have run ten years ago. This is undeniably a huge advance on previous best practices, but it does bring with it a new challenge: how to triage and manage all of the test failures? This talk will investigate the implications of this challenge and shall examine techniques and technologies that can overcome it. Only then can CI finally deliver on its promise.

Assume, we implement a very simple class having a string as member.

As an ordinary Application Programmer:

Even if you want to have the best performance!

You think you know the answer? Well, you might be wrong!

Let’s look at a simple class with a string member and see the effect using different implementation approaches (using constructors passing by value, by reference, or doing more sophisticated tricks).

Sooner than later we will fall into the deep darkness of universal references and enable if…​

Ask programmers what comes to mind when you say concurrency and most are likely to say threads. Ask what comes to mind when you say threads and most are likely to say locks or synchronisation. These assumptions are so deeply held that they define and constrain how programmers are taught and think about concurrency: thread safety is almost synonymous with the avoidance of race conditions and the guarded protection of mutable state. But this is only one quadrant of four possibilities, a quadrant diagram partitioned by mutable–immutable along one axis and shared–unshared along another.

Whether C++, C# or Java, many mainstream languages support programmers in all four quadrants, not just the synchronisation quadrant. From immutability to actors, this talk will take a look at patterns and practices that encourage thinking and coding outside the locked box.

Will C++ continue growing forever? Can C++ code be simplified? The current C++ reflection proposals are game-changers in themselves, but talk assumes them and asks the question: What could be the next step beyond that, that is enabled once we have reflection? Can it help us to simplify future C++ code? progress more future C++ language feature proposals as just ordinary libraries instead without always requiring a new compiler? replace widely-used but nonportable vendor extensions? … or perhaps all of the above?

This is a brand-new talk of material I’ve never given before, in which I’ll present one of potential future proposals I’m personally working on to further improve C++ post-C++17, all of which follow a common theme – adding a strategic language and/or library feature to C++ that leads to significant, and sometimes dramatic, simplification of real-world C++ code.

Recent European financial regulations have required "traceable time". The ability to prove the correctness of you timestamps relative to a defined reference such as UTC. The first such requirement within civilian industries.

In this talk, we will take a look at the regulations and why they are challenging. We will define some words with which we can describe time readings, look at how time arrives at our machines, how we trace it, and how std::chrono and in fact all current programming languages lets us down.

We will then look into the future and see how the hard to do will become increasingly harder; we’ll suggest why this is not just for the banks and hedge funds, how provably accurate wall clock time is going to be increasingly important in a connected, heterogeneous world.

Finally, we will have a look at what we can to rectify these shortcomings and propose some ideas around abstract APIs and possible underlying implementation options. This latter part of the session, in particular, will seek thoughts and comments from the audience on architecture specific constraints/solutions.

This talk should be easily accessible to all levels, though an interest in how computers measure time will be useful.

Those in Banking/Finance and also high-performance distributed (grid/cloud) computing will find direct relevance. Internet of Things, self-driving cars, and multimedia broadcasting should also find relevance.

Microservices are hell, quite literally. As architectural styles go, rarely has a style asked so much from the developers who are tasked with building systems.

In this talk Russ Miles will be joined by his colleagues, Gibson and the Bot, to talk about the nature of this hell and how they’re working to overcome it using new tools, approaches and, yes, languages.

A popular technique in unit testing is to break dependencies by replacing collaborators of the unit under test with mock objects. Mocking frameworks makes it easier to create mock objects.

Trompeloeil is a new, open source, mocking framework written in C++14. It is easy to use while also allowing great expressive power.

This presentation will show how to use Trompeloeil by following the step-by-step development of an example program using TDD (test driven development.) The example will begin with the most basic usage and go on to cover increasingly more advanced topics, including:

The presentation will also include call outs for participation to help further the development.

Level: intermediate→advanced

It sounds counter-intuitive, but limiting work in progress actually improves the flow of your team. In this workshop you will experience this firsthand. We will be experimenting with several approaches to increase throughput, without changing the actual work.

The SG13 subgroup, HMI or Human-Machine Interface, seeks to offer a 2D graphics API to the standard committee. This is a considerable improvement on stdout when it comes to output from programs.

One advantage such an API offers is a standard platform for game development: currently, one has to choose from a considerable array of libraries and engines such as OpenGL, DirectX, SDL, SFML, and so on. The job of merely creating and displaying a window is deeply non-trivial.

This talk will consider the prospect of developing games using only standard C++. It will cover the options available for the single developer learning to write games, and how this may change with the adoption of this new API. It will include plenty of simple examples and consider how this might change how C++ is taught and how this increases accessibility to school-age learners.

We will also write a game together. Live.

Behaviour Driven Development is an agile development technique that improves collaboration between technical and non-­technial members of the team, by exploring the problem using examples. These examples then get turned into executable specifications, often called ‘scenarios’. The scenarios should be easy to read by all team members, but writing them expressively is harder than it looks!

In this 90 minute workshop you will learn how to write expressive BDD scenarios. We’ll start by giving you a very brief introduction to BDD. You’ll then be introduced to different writing styles by reviewing pre­prepared scenarios. If there’s still time, you’ll get a chance to write your own scenarios based on examples that we’ll bring along.

We’ll be using Gherkin, the syntax used by Cucumber and SpecFlow ­ but you won’t need a computer.

Traditionally, memory usage analysis and memory leak analysis for C and C++ programs involve instrumenting either source code or binary code before running it through a series of tests. Such an approach, depending on how aggressively the code is instrumented, either results in false leaks, if the code is not sufficiently instrumented to completely understand whether allocations are still in use, or distorts the timing so much that it is not practical to run on a regular basis. What is worse, if the memory usage of interest happened using code that was not instrumented, it may not be practical to reproduce the problem, for example due to dependence on some obscure code path or on some test that is expensive to run.

At VMware I have developed a tool called ah64 that avoids these issues by analyzing un-instrumented core files, either live cores or cores from crashes, for leaks and memory usage and corruption. It does not report any false leaks and is sufficiently reliable that we run it in an automated way to catch leaks before they are checked in to our code base. We also use it regularly to understand memory growth issues and cases of memory corruption.

VMware is making this available as open source. At present it is working only for Linux ELF cores generated with programs that use libc malloc, and mostly working with windows MDMP files. Some expected areas of growth are likely to include support for other allocators, such as tcmalloc and jemalloc, support for other dump formats, better scripting, and use of DWARF information to make usage analysis more precise.