Document number: N3601

Date: 2013-03-17

Implicit Template Parameters

by Mike Spertus

The purpose of this example is to eliminate the need for the redundant template<typename T, T t> idiom. This idiom is widely used, with over 100k hits on Google.

Document number: N3600

Date: 2013-03-16

C++ Latches and Barriers

by Alasdair Mackintosh

We propose a set of commonly-used concurrency classes, some of which may be implemented using efficient lock-free algorithms where appropriate. This paper describes the latch and barrier classes.

Document number: N3599

Date: 2013-03-13

Literal Operator Templates for Strings

by Richard Smith

N2765 added the ability for users to define their own literal suffixes. Several forms of literal operators are available, with one notable omission: there is no template form of literal operator for character and string literals. N2750 justifies this restriction based on two factors:

• there may be demand for a raw form of string literal, in which

  "Hello, " L"Worl\u0044!"

  is distinguishable from

  L"Hello, World!"

  but this interacted badly with phases of translation, and
• no compelling use cases for this feature were known.

Neither of these is still true, and we now have evidence that a literal operator template for string literals would be valuable; indeed, in one codebase where literal operators are not yet permitted, this form of literal operator has been requested more frequently than any of the forms which C++11 permits.

Document number: N3598

Date: 2013-03-12

constexpr Member Functions and Implicit const

by Richard Smith

In C++11, constexpr member functions are implicitly const. This creates problems for literal class types which desire to be usable both within constant expressions and outside them...

Document number: N3597

Date: 2013-03-15

Relaxing Constraints on constexpr Functions

by Richard Smith

This paper explores the removal of most of the restrictions on constexpr function definitions, in order to make them a simpler and more uniform extension of runtime C++ code. Idiomatic C++ code would be permitted within constexpr functions, usually with little or no modification from its non-constexpr form other than the addition of the constexpr keyword.

Document number: N3596

Date: 2013-03-15

Code Reuse in Class Template Specialization

by Peter Gottschling

The possibility to define specializations of class templates offers an enormous liberty unthinkable in most other languages. Techniques like enable_if would not be possible without this flexibility.

However, in my (personal) experience over 90% of class specializations duplicate over 80% of the implementation. Conversely, the flexibility praised before is only used in few template classes and paid by code duplications in many classes. We propose a simple extension that provides full
backward compatibility and avoids a lot of duplications.

Document number: N3595

Date: 2013-03-15

Simplifying Argument-Dependent Lookup Rules

by Peter Gottschling

ADL rules as defined today are not always intuitive to me -- and I dare to postulate: for Joe Coder neither. Especially, when unintended overloads for common function names (e.g. "size") are accidentally found, they can hide the intended overload and require the programmer to write much more code to get the right overload called. I speak from experience. David Abrahams is fighting since a long time that programmers have more control over ADL: [Abr04, Abr12] and many other documents. Other modications were proposed by Herb Sutter [Sut06].

Document number: N3594

Date: 2013-03-13

std::join: An Algorithm for Joining a Range of Elements

by Greg Miller

Creating a string by joining the elements in a collection with a separator between each element is a common task in many applications. Often the elements themselves are strings, so joining them is fairly straight forward. However, it is not uncommon to join collections of types other than string. For example, one might want to log a collection of int identifiers with each value separated by a comma and a space. In this case there needs to be some way to format the collection's element type as a string.

The std::join() API described in this paper describes a function that is easy to use in all the common cases, such as joining strings and string-like objects as well as primitives like int, float, etc. This API is also extensible through a Formatter function object and is able to join arbitrary types.

Joining strings is the inverse of splitting strings and they are often thought of together. This proposal describes a joining function to go along with the std::split() function described in N3593 (std::split).

This proposal depends on or refers to the following proposals:

• N3593 (std::split)
• N3609 (std::string_view)
• N3513 (Range support)

Document number: N3593

Date: 2013-03-13

std::split(): An Algorithm for Splitting Strings

by Greg Miller

Splitting strings into substrings is a common task in many applications. When the need arises in C++, programmers must search for an existing solution or write one of their own. A typical solution might look like the following:

    std::vector<std::string> my_split(const std::string& text, const std::string& delimiter);

A straightforward implementation of the above function would likely use std::string::find or std::string::find_first_of to identify substrings and move from one to the next, building the vector to return. This is a fine solution for simple needs, but it is deficient in the following ways:

• Must be reimplemented by each individual/organization
• Not adaptable to different types of delimiter, such as regular expressions
• Not adaptable to different return types, such as std::set<string>

Google developed a flexible and fast string-splitting API to address these deficiencies. The new API has been well received by internal engineers developing serious applications. The rest of this paper describes Google's string splitting API as it might appear as a C++ standard.

This proposal depends on the following proposals:

• N3609 (std::string_view)
• N3513 (Range support)

Document number: N3592

Date: 2013-03-15

Alternative Cancellation and Data Escape Mechanisms for Transactions

by Torvald Riegel

Cancellation refers to the ability to cancel the execution of an atomic transaction: When a transaction cannot or does not want to continue execution until it commits, it can stop execution and roll back the actions done so far as part of the transaction. Conceptually, this has always been a part of transactional systems, for example to ensure failure atomicity (i.e., make sets of operations execute completely or not at all even when some of the operations might fail). Even though Transactional Memory (TM) currently focuses primarily on using transactions for concurrency control and not failure atomicity, there are use cases for the latter too (e.g., guaranteeing program invariants in concurrent settings, or speculative execution).

In what follows, I will describe cancellation and data escape mechanisms for transactions as specified by the current draft specification and the changes summarized in N3589. These are supposed to replace the cancellation mechanisms in the current draft (i.e., the __transaction_cancel keyword and the cancel-and-throw functionality); they are compatible with the minimal exceptions proposal described in N3589. The data escape mechanisms allow transaction to communicate data out of cancelled transactions (i.e, the data escapes the transaction's atomicity). Also, whenever I refer to transactions, this always means atomic transactions, not the relaxed transaction variant.

The cancellation mechanisms described here are supposed to serve as a foundation for higher-level features that make use of cancellation, such as composable forms of error recovery or more focused kinds of speculative execution. They also try to provide cancellation with no language extensions or changes (besides a minor extension to the syntax of transaction statements); most of the functionality can be expressed as library features. Likewise, it can be implemented in just the TM-specific implementation parts.