CppCon 2014

C++ is a programming language with a long, storied history spanning over three decades--four if one includes its C ancestry. The C++ language has undergone many changes during that time, compiler technology has advanced substantially, and computers today are very different from the computers of decades past. But despite all of these advances, there's an awful lot of C++ code in use today that looks like it was written in the 1980s. In some cases, the code was written in the 1980s and it's still in use; in other cases, it's recently-written code that just doesn't use modern style.

In this talk, we'll discuss some of the problems with legacy code, and review some practical techniques for applying principles of modern C++ to gradually improve the quality of legacy code and improve maintainability and debuggability. We'll show how some very small changes to code can yield huge benefits.

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.

In our component-based development methodology, each developer is responsible for ensuring that the software he or she creates is easy to understand and use, and not especially easy to misuse. One common form of misuse is to invoke a library function or method under circumstances where not all of its preconditions are satisfied, leading to undefined behavior. Contracts having undefined behavior are not necessarily undesirable, and (for many engineering reasons) are often optimal. Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected, although these same folks might not agree on what specific action should be taken. Unfortunately, validating preconditions implies writing additional code that will execute at runtime. More code runs slower, and some would fairly argue that they should not be forced to pay for redundant runtime checks in the library software they use. Whether and to what extent library functions should validate their preconditions, and what should happen if a precondition violation is detected are questions that are best answered on an application by application basis - i.e., by the owner of main. "Defensive Programming Done Right" makes it all possible.

In this talk, we begin by reviewing the basic concepts of Design-By-Contract (DbC), and what we mean by the term "Defensive Programming" (DP). We then explore our overall approach to institutionalizing defensive programming in robust reusable library software such that each application can conveniently specify both the runtime budget (e.g., none, some, lots) for defensive checking, and also the specific action to be taken (e.g., abort, throw, spin) should a precondition violation occur. Along the way, we touch on how modern compilers and linkers work, binary compatibility, and the consequences of possibly violating the one-definition rule in mixed-mode builds. We conclude the talk by describing and then demonstrating our "negative testing" strategy (and supporting test apparatus) for readily verifying, in our component-level test drivers, that our defensive checks detect and report out-of-contract client use as intended. Actual source for the supporting utility components will be presented throughout the talk and made available afterwards.

Meet C++ AMP (Accelerated Massive Parallelism), an abstraction layer on top of accelerators such as GPUs. In its current version it allows you to run code on any DX11 GPU, independent of the vendor, and it will even distribute workload across GPUs of different vendors simultaneously. C++ AMP was originally designed by Microsoft but is now an open standard. C++ AMP can deliver orders of magnitude performance increase with certain algorithms by utilizing the GPU to perform mathematical calculations. This talk will give a high level overview of what C++ AMP is and what it can do for you. It is time to start taking advantage of the computing power of GPUs!

There would be two types of attendees - library authors and observers.

a) Each library author would make a very short presentation (3 min) of what the library attempts to accomplish.  To be eligible, a library must have documentation.

b) Authors draw lots to select a library other than their own.  Observers are also permitted to draw lots or just select a library they might be interested.

c) Each selected library is “critiqued” by investigating the library and keeping a contemporaneous log on the experience.  I’ll prepare a place where these critiques can be posted. 

d) I will be available to answer questions and provide encouragement.  Hopefully I can convince another boost author to show up.

So the timing would be:

8:30 - short introduction by me to describe the rules above.

8:35 - author presentations - assume 7

9:00 - drawing of lots - critique period begins

(9:15 - first session ends, second session begins in the same room, some attendees may switch sessions)

10:00 - pencils down - wrap up.

If there is demand, this session could be repeated subsequent evenings.

There would be two types of attendees - library authors and observers.

a) Each library author would make a very short presentation (3 min) of what the library attempts to accomplish.  To be eligible, a library must have documentation.

b) Authors draw lots to select a library other than their own.  Observers are also permitted to draw lots or just select a library they might be interested.

c) Each selected library is “critiqued” by investigating the library and keeping a contemporaneous log on the experience.  I’ll prepare a place where these critiques can be posted. 

d) I will be available to answer questions and provide encouragement.  Hopefully I can convince another boost author to show up.

So the timing would be:

8:30 - short introduction by me to describe the rules above.

8:35 - author presentations - assume 7

9:00 - drawing of lots - critique period begins

(9:15 - first session ends, second session begins in the same room, some attendees may switch sessions)

10:00 - pencils down - wrap up.

If there is demand, this session could be repeated subsequent evenings.

The Joint Strike Fighter (JSF) is the first major DOD aircraft program to use C++. Much of this software is either safety critical or mission critical and so must be written in such a way as to be clear, readable, unambiguous, testable, and maintainable. We discuss the driving requirements behind the standard and its evolution. We give a quick overview of our standard and discuss how it differs from later standards such as MISRA C++. We discuss lessons learned over our nine year history of applying the standard to a large embedded software program. We also address ambiguities in rules and difficulties with automated checking of conformance with the standard.

Are you 100% confident that your code is exception-safe?

Safe usage of exceptions is a non-trivial problem that the industry has struggled with for the better part of two decades. If you have fear, uncertainty, or doubt about exception safety or just want to see the best practices for using exceptions in C++ and/or C++11/14, this session is for you. We'll start with "What is the problem we are trying to solve?" and discuss alternatives, acknowledge the challenges associated with exception usage, and cover some well-meaning but misguided attempts at safety. I will then present a set of guidelines that are the basis for safe exception usage and solid implementation techniques, including how to transition from an exception-unsafe legacy code base.

When we are finished you will know how to produce code that is easier to write, easier to understand, faster, and 100% robust in the face of exceptions.

Are you 100% confident that your code is exception-safe?

Safe usage of exceptions is a non-trivial problem that the industry has struggled with for the better part of two decades. If you have fear, uncertainty, or doubt about exception safety or just want to see the best practices for using exceptions in C++ and/or C++11/14, this session is for you. We'll start with "What is the problem we are trying to solve?" and discuss alternatives, acknowledge the challenges associated with exception usage, and cover some well-meaning but misguided attempts at safety. I will then present a set of guidelines that are the basis for safe exception usage and solid implementation techniques, including how to transition from an exception-unsafe legacy code base.

When we are finished you will know how to produce code that is easier to write, easier to understand, faster, and 100% robust in the face of exceptions.

Are you 100% confident that your code is exception-safe?

Safe usage of exceptions is a non-trivial problem that the industry has struggled with for the better part of two decades. If you have fear, uncertainty, or doubt about exception safety or just want to see the best practices for using exceptions in C++ and/or C++11/14, this session is for you. We'll start with "What is the problem we are trying to solve?" and discuss alternatives, acknowledge the challenges associated with exception usage, and cover some well-meaning but misguided attempts at safety. I will then present a set of guidelines that are the basis for safe exception usage and solid implementation techniques, including how to transition from an exception-unsafe legacy code base.

When we are finished you will know how to produce code that is easier to write, easier to understand, faster, and 100% robust in the face of exceptions.

In order to let more people experience type safety and other compile time constraints when programming SQL in C++, more connectors for sqlpp11 are required. Currently there are connectors for MySQL/MariaDb, Postgresql and Sqlite3, as well as an experimental binding to std::vector.

I would like to use the opportunity of having so many capable people in one place to try to add a few more connector libraries. These libraries would not be finished by the end of the day, but there are pretty good chances to get the first few queries processed.

 

"The compile time query checks are brilliant." dirkvdb

sqlpp11 is an EDSL for SQL in C++, allowing you to write SQL queries in name- and type-safe manner. You can learn a lot about how it works and how you benefit from it in my talk on Thursday.

sqlpp11 is vendor neutral. In order to work with a database, it requires a connector library. Such libraries are available for MySQL/MariaDb, PostgreSQL, Sqlite3 and (experimental) std::vector.

I want to use the opportunity of having so many highly capable developers in one place: Lets write a few more connector libraries. These could be for SQL databases, like Microsoft SQL, Oracle, Firebird, MemSQL, DB2 etc. If you're feeling more adventurous, we could at least start writing connectors to other databases, e.g. incoming JSON streams, or we could improve on the connector to C++ standard containers.

I'll start with a short introduction about what a connector looks like and how it is typically structured. After that we start coding (in teams, maybe). I will provide a skeleton so that you don't have to worry less about structure and boiler plate. I am sure that we will be successfully processing the first queries with new connectors by the end of the session.

Anyone can participate. It would be helpful if you

• bring a laptop
• are able to compile sqlpp11 (this is known to work for gcc>=4.8 and clang>=3.1)
• have a connector in mind you want to write/work on
• have some knowledge and access to the documentation of the interface of the database for that connector

Jens and Jon will share their experiences starting and working with local user groups and C++ conferences. They share some history and pointers on what has worked for them.

If you'd like to start or be active in a local tech group this session will be a good place to start.

Memory is an important property for every object, as whatever resources it manages, it must occupy some memory. THe ability to customize memory allocation is important for every C++ program that cares about performance, debug ability and support.

The original C++ standard supported an allocator parameter for every container, yet this feature was widely derided or ignored, as it was underspecified to the point it could not portably be used. C++11 makes significant changes to the allocator model, that simply its use while making it more powerful.

The Library Fundamentals TS goes further, allowing allocators' type to be supplied at runtime, rather than compile type, using classic object oriented polymorphism - yet building on the infrastructure laid down in C++11.

This material should be of interest to both library authors and consumers, although clearly there are more details for the implementers to absorb. It also includes an interesting case study in C++11 compile time reflection, as required to implement the new 'allocator_traits' facility.

Memory is an important property for every object, as whatever resources it manages, it must occupy some memory. THe ability to customize memory allocation is important for every C++ program that cares about performance, debug ability and support.

The original C++ standard supported an allocator parameter for every container, yet this feature was widely derided or ignored, as it was underspecified to the point it could not portably be used. C++11 makes significant changes to the allocator model, that simply its use while making it more powerful.

The Library Fundamentals TS goes further, allowing allocators' type to be supplied at runtime, rather than compile type, using classic object oriented polymorphism - yet building on the infrastructure laid down in C++11.

This material should be of interest to both library authors and consumers, although clearly there are more details for the implementers to absorb. It also includes an interesting case study in C++11 compile time reflection, as required to implement the new 'allocator_traits' facility.

Highly performant and scalable techniques such as RCU and hazard pointers have been quite successful in read-mostly situations. However, there do come times when updates are necessary. It would be convenient if there was some general update-side counterpart to these techniques, but sadly there is not yet any such thing. Nevertheless, there are a number of specialized update-side techniques whose performance and scalability rival those of RCU and hazard pointers. This talk will discuss several of them, one of which is a solution to a challenge to the speaker at the 2014 Issaquah C++ standards committee meeting. This talk will also provide an outlook into the future of low-overhead scalable updates.

JUCE (Jules' Utility Class Extensions) is an all­encompassing C++ class library for developing cross­platform software. It contains a number of classes allowing to create standard applications, and is particularly well­suited for building audio and real­time applications. In addition to the classes, JUCE offers support for linking and managing libraries and dependencies with dedicated software, the Introjucer. The Introjucer creates templates for most popular compiler environments that make the compiling toolchain simpler and faster.  

Come and learn about JUCE: What is it? Who uses it? What do they use it for? How does it work? What exciting things are planned for its future? We'll present a short talk about a few of the library's noteworthy features, and invite the audience to join in with questions and opinions. We hope this session will be interesting for people who've never heard of JUCE, and also for those who use it every day!

Type erasure looks like a neat concept, but what are its real life uses? This talk will briefly show the inner workings of type erasure, and demonstrate a real working implementation of a configuration system from public domain production code. Uses and pitfalls of type erasure will also be covered.

Dive into and follow along making a lock-free queue.

In particular, a multi-producer, multi-consumer, growing, shrinking, mostly contiguous, lock-free circular queue.

With this single (complicated!) example, we will come across, and attempt to solve, many of the typical problems found in lockfree programming, and delve into the pros and cons of various solutions to those problems.

Video games like Assassin's Creed or Rainbow Six are among the biggest code bases with a single static linking. Iteration-time is critical to develop a great game and keeping a complete compilation-time of a few minutes is a constant challenge. This talk will explain the C++ usage reality at Ubisoft Montreal for huge projects. Ideas will be shared regarding performance, debugging and iteration time.

Multicore hit the video game industry in a big way. Every platform we develop for now comes in a multicore configuration, and we're always under pressure to exploit the hardware to its fullest. This talk will share our experience learning to develop C++ software for multicore processors over the last decade. It will also explore the new concurrency support in C++11, and examine the way C++11 has influenced the way we develop multicore software so far.

In order to let more people experience type safety and other compile time constraints when programming SQL in C++, more connectors for sqlpp11 are required. Currently there are connectors for MySQL/MariaDb, Postgresql and Sqlite3, as well as an experimental binding to std::vector.

I would like to use the opportunity of having so many capable people in one place to try to add a few more connector libraries. These libraries would not be finished by the end of the day, but there are pretty good chances to get the first few queries processed.

We will continue to develop the connectors we started in Part 1. Depending on how far we got, there are several options, for instance

• Support for prepared statements
• Add connection pools
• Turn off unsupported features at compile time
• Add vendor specific SQL extensions to the EDSL, like hierarchical queries for Oracle for instance

I will give short introductions to these topics and help you with the implementation. Some of those will be challenging!

Since the overlap between topics is relatively small, several people could work on the same connector in parallel.

C++17 may bring most efficient, most scalable, most open/customizable coroutines of any programming language in existence. Stackless Resumable Functions are the proposed for standardization lightweight coroutines that scale to 100,000,000 of concurrent coroutines, allow to consume existing any asynchronous OS APIs / libraries with zero-overhead adapters and allow library designers go wild, invent new coroutine types and plug them into Resumable Stackless Functions machinery.

We will look at examples of tasks, goroutines, generators running on top of resumable functions. We will explore implementation details of how they actually work and look at the customization machinery that allows library designers and ordinary users to extend coroutines as needed.