Document number: N3604

Date: 2013-03-18

Centralized Defensive-Programming Support for Narrow Contracts

by John Lakos, Alexei Zakharov

In this proposal, we describe a centralized facility for supporting defensive runtime validation of function preconditions. What makes this overall approach ideally (and uniquely) suited for standardization is that it allows the application to (1) indicate coarsely (at compile time) the extent to which precondition checking should be enabled based on how much defensive overhead the application (as a whole) can afford, and (2) specify exactly (at runtime) what action is to be taken should a precondition violation be detected.

Document number: N3603

Date: 2013-03-17

A Three-Class IP Address Proposal

by Christopher Kohlhoff

This proposal describes a three-class design for IP address classes:

Document number: N3602

Date: 2013-03-14

Template Parameter Deduction for Constructors

by Mike Spertus

This paper proposes extending template parameter deduction for functions to constructors of template classes. The clearest way to describe the problem and solution is with some examples.

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].