Document number: N3889

Date: 2014-01-20

Concepts Lite Specification

by Andrew Sutton

C++ has long provided language support for generic programming in the form of templates. However, these templates are unconstrained, allowing any type or value to be substituted for a template argument, often resulting in compiler errors. What is lacking is a specification of an interface for a template, separate from its implementation, so that a use of a template can be selected among alternative templates and checked in isolation.

Document number: N3887

Date: 2013-12-26

Consistent Metafunction Aliases

by Michael Park

This paper recommends a systematic guideline to steer future WG21 decisions in deciding when a metafunction-name_t template alias should accompany a standard library metafunction. After applying this recommended guideline to the entire C++14 standard library, we conclude that tuple_element_t is the only missing alias. We then propose wording (a) to remedy this lack and (b) to take advantage of the proposed remedy. Finally, we also present an alternative guideline and its implications, and provide justications for favoring the recommended guideline.

Document number: N3886

Date: 2014-01-18

A Proposal to add a Database  Access Layer to the Standard Library

by Johann Anhofe

This document describes an easy to use database abstraction layer for C++. It describes a set of classes which can be used to access an arbitrary SQL based relational database system."

There exist a lot of different database systems in the world, with a lot of different API’s for accessing data within a C++ program. The most API’s are in plain old C, which make the usage even harder for novice programmers. So we need a simple harmonized layer which can be easily extended for new database systems and also easily used by programmers.

Document number: N3884

Date: 2014-01-20

Contiguous Iterators: A Refinement of Random Access Iterator

by Nevin Liber

This is a proposal to add contiguous iterators to the standard, which is a refinement of random access
iterators.

A contiguous iterator is a random access iterator that also meets the following requirements:

std::pointer_from(i) == std::addressof(*i) (when i is dereferenceable)

std::pointer_from(i + n) == std::pointer_from(i) + n (when i + n is a valid iterator)

Document number: N3883

Date: 2014-01-17

Code checkers & generators

by Németh Péter

Native Json & HTML, built-in tutorial, easy meta programming, reflection proposal to C++.

Document number: N3882

Date: 2014-01-17

An update to the preprocessor specification

by David Krauss

The C preprocessor specification inherited by C++ uses undefined behavior to specify latitude for implementation differences. This technically allows one compiler to produce a defective executable from a particular program, while another fills the void with useful features. In theory this makes porting programs dangerous, but in practice consensus has been reached regarding the meaning of most programs invoking undefined behavior, and programmers have little reason to worry. By capturing the status quo in the standard, safety can be properly guaranteed, and the preprocessor may be more completely understood without referring to platform documentation.

Additionally, the preprocessor has not kept pace with C++11 lexical extensions (raw strings, user-defined literals, and new encoding prefixes), resulting in unspecified corner cases.

This proposal updates the preprocessor specification to remove undefined behavior, missing specifications, and possible contradictions, and to better document implementation differences.

Issues related to universal-character-names are not addressed here, but in N3881.

Document number: N3881

Date: 2014-01-03

Fixing the specification of universal-character-names

by David Krauss

There are two main problems with the current specification of UCNs, which remains essentially the same as initially standardized.

1. Undefined behavior is an undesirable kind of specification, because it technically allows the implementation to quietly produce a defective executable file. There is consensus that errors in preprocessor usage should not have runtime consequences. There is even a CERT security advisory about UCNs causing undefined behavior. N3801 "Removing Undefined Behavior from the Preprocessor" directly addresses this by recommending to convert undefined behavior specifications to ill-formedness.
2. There are corner cases which are not specified as undefined behavior. These may be welldefined and misinterpreted, or ill-formed yet undiagnosed, by popular implementations, or simply excessively restrictive. Underspecified cases undermine the effect of N3801 by remaining wrongly defined.

The present paper will review several corner cases, considering the natural response of models A,
B, and C, and the actual behavior of GCC and Clang. This leads to a specification permitting
implementation flexibility without ambiguity, and bringing existing compilers into conformance.

Document number: N3879

Date: 2014-01-17

Explicit Flow Control: break label, goto case and explicit switch

by Andrew Tomazos

We propose adding to C++ some new jump statements and making available an explicit-specifier for
switch statements.

The new jump statements are break label, continue label (same as Java), goto case constant-expression
and goto default (same as C#).

An explicit switch statement (same as C#) causes each case block to have its own block scope, and to never flow off the end. That is, each case block must be explicitly exited. (The implicit fallthrough semantic between two consecutive case blocks can be expressed in an explicit switch using a goto case statement instead.)

Document number: N3878

Date: 2014-01-13

Extensions to the Concept Introduction Syntax in Concepts Lite

by Botond Ballo and Andrew Sutton

In this paper, we propose a few small extensions to concept introductions. We believe these extensions will make the language more expressive and fill some holes in the Concept Lite proposal.

Document number: N3877

Date: 2014-01-17

Centralized Defensive-Programming Support for Narrow Contracts (Revision 3)

by John Lakos and 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. Moreover, the flexibility of this supremely general solution to precondition validation lends itself to a thorough, yet surprisingly easy-to-use testing strategy, often called negative testing, for which a supportive framework is also provided. Finally, this general approach to implementing and validating defensive checks is not just a good idea: It has been successfully used in production software at Bloomberg for over a decade, was presented at the ACCU conference in 2011, and is currently available along with copious usage examples embedded in running library code as part of Bloomberg’s open-source distribution of the BSL library at https://github.com/bloomberg/bsl.