CppCon 2018

Challenge: Write a library function template that takes exactly one positive, integral parameter.

There are many different ways to implement this function template in standard C++. The future additions of Concepts and Contracts will provide even more, possibly simpler, implementations as well. We will review the current status of both of these important new features, conduct a brief overview of what they can do, and then examine how they can work together towards an interface specification nirvana.

This talk will focus on C++ function templates and such allied topics as compiler-synthesized function template declarations/signatures, overload resolution and partial ordering of these declarations, and compiler instantiation of function template definitions.

We’ll also look at function template specialization, explaining why to avoid explicit ones, and recommending what to do instead.

Finally, time permitting, we’ll offer advice for customizing function templates in the standard library, especially in light of recent WG21 developments re customization points.

This is a two part session about writing and using contracts
to specify code in C++.

Contract Programming in C++ (first session)
Contract Programming in C++20 (second session)

The first session will define the fundamental princple that
all software is build on: contracts as an exchange of promises
between API authors and consumers. This first session will look
at how deep these promises go, down into the language specification
and design, and how we can effectively write and test our contracts
using C++ from the original C++98 standard up through more modern
dialects. Finally, the properties of good and bad contracts will be
studied, with an emphasis on how they impact API design.

The second session will quickly recap the first session, before
jumping into the details of new proposals for C++20 that allow
contracts to be more clearly expressed in the language. New
features include contracts that can be tested and queried at
compile-time through the type system (Concepts), and support for
writing and testing contracts on object values at runtime, with
direct support for contracts in new attributes. Finally, the
advice regarding good and bad contracts will be revisited in
light of the new language support.

Ever thinking of creating your own specific-purpose programming language? Or maybe improving programming experience by adding a language feature in existing language? This talk presents about Embedded Domain-Specific Language (EDSL) from basic concepts and technique to build it using C++.

EDSL is a powerful technique in integrating a custom libraries or frameworks in users’ codes. EDSL can improve user’s experience in using libraries by reducing boilerplate codes and providing more readable and straightforward codes. Some success stories are: Boost.Spirit, Boost.Proto.

Although Boost.Proto provides tool to build EDSL in C++, this talk presents building EDSL from the ground up utilizing operator overloading, template metaprogramming, and macro. We use operator overloading and template metaprogramming to build a simple expression tree for our EDSL.

This talk provides an example of developing an “asynchronous block” within C++ codes to be used in Tizen native application development. The “asynchronous block” has similar purpose with C++11 std::async but targeting a different API and mimicking the structure of try-catch block.

This is a two part session about writing and using contracts
to specify code in C++.

Contract Programming in C++ (first session)
Contract Programming in C++20 (second session)

The first session will define the fundamental princple that
all software is build on: contracts as an exchange of promises
between API authors and consumers. This first session will look
at how deep these promises go, down into the language specification
and design, and how we can effectively write and test our contracts
using C++ from the original C++98 standard up through more modern
dialects. Finally, the properties of good and bad contracts will be
studied, with an emphasis on how they impact API design.

The second session will quickly recap the first session, before
jumping into the details of new proposals for C++20 that allow
contracts to be more clearly expressed in the language. New
features include contracts that can be tested and queried at
compile-time through the type system (Concepts), and support for
writing and testing contracts on object values at runtime, with
direct support for contracts in new attributes. Finally, the
advice regarding good and bad contracts will be revisited in
light of the new language support.

Writing code that is resilient upon errors has always been a pain point in all languages. Exceptions are the politically correct means to signal errors in C++, but many applications still resort to error codes for reasons related to ease of understanding, ease of handling errors locally, and efficiency of generated code.

This talk shows how a variety of theoretical and practical artifacts can be combined together to address error codes and exceptions in one wholesome, simple package. The generic type expected＜T＞ can be used for both local (error-code-style) and centralized (exception-style) manners, drawing from the strengths of each.

A friend of a class is a function or class that is not a member of that class, but nonetheless has access to all members of that class. The conventional wisdom is that granting friendship is something you do should sparingly. This lecture introduces a distinctive use for friend function declarations in class templates that's not about granting access to non-public members. Rather, it's about using a template as a
factory for "making" new friends. Along the way, this session explains various subtleties about operator overloading, overload resolution,
template instantiation, and name lookup for friend functions.

Your code would benefit from greater use of operators. Really.

Operator overloading is such an unloved part of C++. It's not new, it's not
glamorous, it's frequently maligned for "syntax abuse", and often avoided due to
performance or implementation concerns. But operators deserve more
consideration! If you're designing types and interfaces, operators have the
potential to offer concision, clarity, and flexibility, and foster intuition in
a way that functions can't.

In this talk we'll look at past, current and likely future practices, from the
humble old operator+ on arithmetic types to new uses like operator/ to
concatenate paths, and beyond. We'll cover concrete guidelines for principled
operator usage and the implementation concerns involved.

In software things can go wrong. Sometimes we might expect them to go wrong. Sometimes it’s a surprise. In most cases we want to build in some way of handling these disappointments.

In some cases we can use exceptions. But there are many cases where the overhead of exceptions is more than we want or can afford - and some are so constrained that exceptions are not even possible. Alternatives now include std::optional, or the proposed std::expected - but these come with a lot of code overhead

What we really want is a way to concisely produce and handle disappointments in our code in a performant manner. This talk will evaluate a few approaches to solving this, including monads, syntactic sugar for error handling, and we'll even look at an intriguing possibility that promises to unify these worlds.

Support for functional programming has been consistently growing in C++. Lambdas, new algorithms, variant visitation and std::apply are just a few of the many additions which make use of the paradigm more natural, expressive and powerful. Unfortunately, passing overloaded functions or function templates to higher-order functions is not as simple as it sounds, which forces users to adopt various unsatisfactory workarounds. This talk will discuss a few solutions, show how C++ still has a way to go in providing language support, and examine some existing standards proposals which could help.

Techniques discussed will include wrapping up overload sets in lambdas; maintaining noexcept specifications, return types, and brevity; global function objects; and avoiding subtle One Definition Rule (ODR) violations.

Given a function: void foo(int a, int b);

Wouldn't it be great to be able to write? foo("b" = 3, "a" = 2);

This will be a live coding session where we start from the basic idea of what we want to do and build up a small library similar that accomplishes this goal. We will outline some simply but powerful programming techniques and give a brief outline on how to use Hana, a powerful library for metaprogramming.

How many different ways are there to pass an argument? Why do we have so many? Which way should you be using? What does it mean when you use the wrong one?

A function declaration is like the thesis statement in an essay. It should communicate both for the caller and the callee it's purpose, semantics, and side-effects. We often think this communication is in the form of comments, but a function's arguments also convey this information.

This talk will catalog many the different ways to pass arguments. We will then explore which ones are redundant or nonsensical, and give meaning to the ones that remain. We will end with recommendations what types to use to express your intent, and empower you with fundamentals to write clearer function definitions.

The last time the keyword `concept` appeared in the C++ Standard's working draft was July 2009, two years before the release of C++11. Now, in September 2018, two years before the expected release of C++20, the working draft once again contains something called "Concepts" — something very different from what was there before, and — so far — much more conservative than the Concepts TS (formerly known as "Concepts Lite").
What should the forward-looking C++ programmer do and know about Concepts in C++2a? Arthur will attempt to puzzle it all out. What is a "Concept" and why should we care? What is the current syntax for defining and using concepts? What compilers support C++2a concepts syntax today, and how do I enable it? How does it affect name-mangling? What are "atomic constraints," "disjunctive clauses," and "subsumption"? What good are value concepts and template concepts? What is the difference between a "requires clause" and a "Requires element"? What is this "terse syntax" we've been hearing about, and why is it controversial? What is "Giraffe_case" and should I use it? Can I use the "requires" keyword without Concepts?
This material will be presented from an outsider's perspective, which means you can expect Arthur to say at least a few wrong things; and the shelf life of this material will be short, as C++2a Concepts are very much in flux right now. Still, if you want to get caught up on (or in) the Concepts discussion, this might be the place for you.

Wouldn't it be nice to be able to tell the compiler "pick the first piece of code in this list which compiles", "pick the first type which has these properties" or simply be able to ask "does this code compile?". In this talk we will build a set of tools to make this happen using some of the new C++17 features.

SFINAE (Substitution Failure Is Not An Error) has been used for years to do this and to help the writing of generic code. It often required to play with a lot of templates to force the compiler to choose the right overload or specialization, often leading to a lot of boilerplate code. The upcoming concepts, already usable in some compilers as an experimental feature, will simplify a lot of these use cases. However, sometimes, it would be very nice to be able to write "inline" SFINAE directly in application code without having to worry too much with templates. This talk is intended to both metaprogrammers (to write these tools) and developers who want to write very generic code (to use these tools) using C++17.

In this talk, we will build these tools step by step, layer by layer. This will allow to see how some C++17 features like void_t, template deduction guides, invoke and constexpr if can be used. First we will design some additional type traits to play with qualifiers and to retrieve information about callable types. Second, we will design classes to be able to create custom overload sets or overload sequences from functions with different names. Then on the top of it, we will use metaprogramming techniques to design tools to let the user ask questions to the compiler or to pick the first code that compiles from a list. Finally, we will explore some of the very nice applications of these tools, allowing to make interfaces even more generic than before with an elegant and simple syntax.

Class Template Argument Deduction (CTAD) is a C++17 Core Language feature that reduces code verbosity. C++17's Standard Library also supports CTAD, so after upgrading your toolset, you can take advantage of this new feature when using STL types like std::array, std::greater, std::pair, and std::vector. Class templates in other libraries and your own code will partially benefit from CTAD automatically, but sometimes they'll need a bit of new code (deduction guides) to fully benefit. Fortunately, both using CTAD and providing deduction guides is pretty easy, despite template metaprogramming's fearsome reputation!

This presentation will contain three parts: using CTAD in everyday code, providing deduction guides in library code, and understanding corner cases. For everyday code, we'll explore how CTAD makes using the STL easier, eliminating annoying angle brackets filled with redundant info. All programmers, from beginners to experts, will benefit from typing and reading less code. Next, for library code, we'll see how to distinguish situations where CTAD automatically works versus those where deduction guides are needed, and how to write those guides. Finally, we'll examine some corner cases that illustrate how CTAD works in complicated scenarios, including issues recently resolved in the Standard.

The Concepts TS -- the ISO-published Technical Specification for
constrained templates -- was merged into the C++20 Working Paper in
2016. This is a big deal for C++. We've been missing this kind of
language feature for nearly 30 years. Well... now that we have it,
it's probably a good idea to know what it's for and how to use it.

This talk covers basic topics of generic programming using concepts.
I will talk about using concepts to write constrained templates,
overloading constrained functions (why, when, and how), and how to
define good concepts (which is a bit trickier than you might imagine).

I will also discuss some of the changes to the syntax and semantics
of language features in the Concepts TS when it was merged into
the Working Paper for C++20.

Class Template Argument Deduction (CTAD) is a very useful C++ language feature that was added in C++17. This talk is a comprehensive and practice-oriented introduction to this new technique.

In this talk I'll present how CATD and automatic deduction guides let you write cleaner and shorter code, show how to interact with it when using the C++ standard library and when designing your own classes, explain when and how user-defined deduction guides should be used, and cover the language rules behind all of this.

We will also discuss the various pitfalls that lie in wait: wrong and surprising template arguments being deduced, your constructor not being selected even if you think it should be, and automatic CTAD sometimes leading to unsafe and broken code – and how to circumnavigate those pitfalls.

Abstract: This talk explains the relationship between good code and a good human interface (graphical or otherwise). Human interface semantics are tightly coupled with code semantics and improving how we reason about code can have a direct on positive impact on the human interface behavior of the system. Part of my “Better Code” series of talks, the goal is “Don’t Lie.”

We say that interfaces should be easy to use and hard to misuse. But how do we get there? In this talk I will demonstrate how using declarative techniques in APIs, functions, and plain old “regular” code can help.

We’ll look at what is meant by “declarative style” in C++; explore why declarative interfaces are desirable and how to construct them; and take an in-depth look at which features of C++ help us write in a declarative style.

I want to deconstruct C++ a bit, examine what we’re doing and what makes the good parts good, and from that reconstruct some best practices. Many of us are already writing code following piecemeal modern advice such as “no raw loops”, or “almost always auto”, or C++ core guideline recommendations. In many cases, this advice translates to writing more declarative code; being deliberate about exploring and using declarative techniques gives us insight we can apply more widely.