C++Now 2014

It was a simpler time. A period in which every college student and learn-C++-in-a-weekend duffer could write a class with the assuredness that it would behave as desired when assigned and copied. There was a check list. Complete the checklist, add some domain specific behaviour, bake in the regression oven, and you were done.

Enter C++11 with its fancy new use of the delete keyword, additional applications of explicit, rvalue references, and some perfect forwarding. How are you to write a “simple” class? Should you include a swap? What does movable mean and are there expected semantics? When is the noexcept specifier used?

During this 90-minute session we will explore the boilerplate of a C++11 class. The session will touch on rvalue references, move semantics, perfect forwarding, explicit, noexcept, initializer lists, and more as it applies to producing the desired semantics for our classes and structs.

Test-driven development embraces three simple rules:

1. You are not allowed to write any production code unless it is to make a failing unit test pass.


2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.


3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. In short, with Test-Driven Development, you always write production code in response to a failing unit test.

In this tutorial, you will see how to apply the ideas of test-driven development in C++ using the Boost.Test unit testing framework. All the major areas of Boost.Test will be covered from assertions through test case design and organization. We will cover the difference between state-based testing and behavior based testing using mock objects provided through turtle mock, a mock object framework for Boost.Test.

First, you will walk through some exercises designed to show you the mechanics of test-driven development. Next, you will apply the concepts you have learned about test-driven development as a design activity to implement a feature. Once this tutorial is over, you will see how test-driven development is a powerful design activity that will naturally lead you to creating small, cohesive and decoupled classes.

Test-driven development embraces 3 simple rules: 1. You are not allowed to write any production code unless it is to make a failing unit test pass. 2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures. 3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test. In short, with Test-Driven Development, you always write production code in response to a failing unit test.

In this tutorial, you will see how to apply the ideas of test-driven development in C++ using the Boost.Test unit testing framework. All the major areas of Boost.Test will be covered from assertions through test case design and organization. We will cover the difference between state-based testing and behavior based testing using mock objects provided through turtle mock, a mock object framework for Boost.Test.

First, you will walk through some exercises designed to show you the mechanics of test-driven development. Next, you will apply the concepts you have learned about test-driven development as a design activity to implement a feature. Once this tutorial is over, you will see how test-driven development is a powerful design activity that will naturally lead you to creating small, cohesive and decoupled classes.

More and more people are becoming aware of undefined behavior (UB) in C and C++. It has become a research interest at several universities, and code generators routinely use information about UB when deciding how to optimize code. 

In this talk, I will give examples of UB, show how optimizers reason about UB while doing code generation, and talk about strategies to avoid introducing UB into your code base (with examples from Boost). Finally, I will talk about the current (and upcoming) tools for detecting UB in existing code.

This is the first of two presentations on the new features of C++11/14. It covers most of the smaller aspects of the language:

• C++ Timeline


• Goals for C++11/14


• The Simpler Core Language Features


• auto, decltype, trailing return types


• Non-member begin/end


• nullptr


• Range for


• >> in template specializations


• static_assert


• extern template


• noexcept


• Variadic templates


• constexpr functions and data


• Template alias


• New character literal types


• Raw string literals


• Literal strings and const

There's also brief coverage of scoped enums, long long, alignas/of, attributes, inline namespaces, generalized unions/PODs, garbage collection ABI, and user-defined literals.

This is the second of two presentations on the new features of C++11/14. It covers the meatier features added to the language:

• Class design features: default and deleted generated functions, delegating and inheriting constructors, new flexibility for in-class initializers, and explicit conversion operators


• Initialization: initializer lists, uniform initialization, and narrowing prevention


• Lambdas


• Rvalue references: lvalues and rvalues (the modern view), move semantics, universal references, perfect forwarding

In some programming languages, text processing is easy. Unfortunately, C++ is not one of those languages. C++ lacks good, built-in support for Unicode, though the situation is starting to improve.

This session will begin with a brief overview of text encodings, and an introduction to Unicode and the various Unicode encodings.  We’ll look at the woeful state of Unicode support in C++98 (or, really, lack thereof), then take a look at the improvements that were made in C++11 and other improvements that have recently been proposed for standardization.  We’ll finish up with a discussion of several libraries designed to make it easier to work with Unicode in C++, including the widely-used, open-source International Components for Unicode (ICU) library.

Today, heterogeneous programming is ubiquitous across many segments of the C++
industry. Data centers utilize GPGPUs to process vast quantities of data,
supercomputers increasingly draw upon accelerators to provide the bulk of their
computational power, and mobile devices frequently couple "capability" CPUs with
"capacity" GPUs to provide high-efficiency computational power.

Typically, accelerators are only suitable for executing certain portions of a
program. They frequently rely on CPUs to make big-picture execution decisions,
access main memory, and manage peripheral hardware. The interactions between
CPUs, accelerators and other system components makes heterogeneous systems
complex.

Furthermore, accelerators may live off-chip, contain their own
private memory, or have noticeable communication latencies. Heterogeneous
systems may contain multiple CPUs that communicate via vendor-specific
processor interconnects. System complexity can be further complicated by
applications that are storage- or network-intensive.

For many C++ programmers, heterogeneous programming is no longer a luxury;
instead, it has become a necessity. C++14 provides no mechanism for
heterogeneous programming; C++ programmers must rely on software libraries to
harness the power of accelerators. There are numerous high-quality frameworks for
utilizing accelerators, but many of these frameworks are usable only
with certain types of accelerators or emphasize a purely synchronous offloading
model.

The C++ Accelerated Massive Parallelism (C++ AMP) open specification, published
by Microsoft, presents a hardware-agnostic interface for exploiting accelerator
hardware in modern C++ applications. C++ AMP consists of both language
extensions and an STL-like library component. It provides support for both
synchronous and asynchronous offloading. C++ AMP allows programmers to write
accelerator-aware applications without having a detailed knowledge of the
intricacies of heterogeneous hardware.

In addition to the mature C++ AMP implementation provided by Visual Studio, there
a number of C++ AMP implementations for a variety of platforms. To name a
few, Intel is developing an implementation called Shevlin Park and the HSA
foundation is working on a Clang-based C++ AMP implementation.

This tutorial will present an overview of C++ AMP from a software-centric
viewpoint, covering the following topics:

* Programmatically preparing data for accelerators
* Transferring data to/from accelerators
* Offloading code to accelerators (e.g. restrict(amp), parallel_for_each)
* Controlling accelerator parallelism (e.g. tiling, barriers)

This talk will emphasize usage of the asynchronous interfaces provided by C++
AMP to write wait-free offloaded code.

The intended audience is C++ developers who are either using accelerators today
or will be using accelerators in the future. The talk will include limited
discussion of specific accelerator hardware or software implementations of C++
AMP. This presentation will be relevant to developers on all platforms, not just
Windows.

C++11 introduced rvalue references or '&&'. That simple double '&' gives move semantics its mojo. But '&&' is yet more powerful. The power hidden behind both std::move and std::forward is also '&&'. Additionally, you may have heard of Universal References, which also are based on '&&'. 

With all that power, it turns out that '&&' can be a bit tricky. This presentation summarizes the different uses for '&&'. It covers how to distinguish the different roles that '&&' can take on while you are reading or writing code. It also covers current best practices for using '&&' in code. The talk is intended for beginning C++ programmers who want to find out what the '&&' fuss is about or for intermediate programmers who perhaps tried to use '&&' and then didn't get the behavior they expected. 

Refactoring tools for C++ have lagged behind those available in other languages. We've all heard the excuses about how C++ is too hard to parse and too hard to reason about. Well, get ready to have your socks blown off by the tooling infrastructure provided with clang. It makes writing refactoring tools simple and easy.

In this talk, I will incrementally develop a refactoring tool with clang that transforms a "(void)" function argument list to an empty argument list: "()".  This will give you a concrete example of how to apply the tooling library from clang: exploring the parsed abstract syntax tree (AST), writing code that matches elements of the AST, and operating on the matched nodes to create source code transformations that are applied by the tooling library.

If time is available, we'll look at some other examples of refactoring tools and discuss how they operate.

What's the point of functional programming? Don't I have to do that in Haskell? Is functional programming an all-or-nothing thing? Can I benefit from making my C++ "more functional"? If so, how would I do that?

One of the most powerful features of C++ is deterministic, scope based object lifetimes. Used properly, this can help ensure that your code is does not leak resources and is exception-safe. In this talk, I will show examples and discuss techniques that you can use to make your code simpler, easier to read, and more obviously correct. 

We'll start with the basics of construction/destruction, move on to RAII and smart_pointers, then discuss exception safety, and finish up with a discussion about ownership when passing parameters. 

Along the way, I will discuss the changes in C++11 and C+14 that make this style of programming easier.

C has the facility to declare data, both initialized and uninitialized, that is available to whole programs. C++ extends this with the ability to create global and thread-local objects. As with all objects, global and thread-local objects are constructed at the beginning of their lifetimes and destructed at the end.

This talk will cover what the C++11 standard guarantees concerning global, static, and thread-local object lifetimes.  It will then cover what compilers actually do.  How to use global data for complex initialization will be discussed.  Patterns for dealing with global data and how to minimize global data will also be discussed.

Let's face it, for large applications where blocking while waiting for a future is not an option, std::async doesn't make the cut. N3558 and N3650 still do not solve the problem.

Would an ASIO-style callback-based solution be better?

We will first study a Qt application (a CD Player) where the functional behavior will be provided by Boost Meta State Machine and the asynchronous part by the upcoming Asynchronous library.

The second part of the talk will be more focused on the Asynchronous library: Active Objects, threadpools, algorithms, and much more.

In this talk, we will cover various popular methods of defining ownership of an object: automatic variables ("stack based"), raw pointers, and smart pointers. We also put forth a minor improvement to the collection of smart pointers available in the C++ standard library. 

Most treatments of the ownership topic in C++ briefly mention performance (if at all), with most of the focus being on simply convincing people to use (or not use) them. This talk, however, will have a significant component dedicated to how to effectively optimize time and memory usage while retaining correctness. 

The focus of this talk will be on ownership as it relates to memory. We will briefly touch on important principles such as RAII, but only in the context of memory management, not general resource management. 

Overloading gives C++ function calling much greater flexibility than C's.  However, overloading can lead to ambiguities, for which there are common tools: SFINAE, MPL's integral_constant, and tag dispatching.  However, using those tools is a black art compared to just renaming functions. In this talk, we will learn how to use those tools to manage function overload sets.  We will also discover when you must, should, should not, or cannot disambiguate function calls with those tools.

Examples come from implementations of library proposals, libc++, libstdc++, and Boost. MPL experience is not required.