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.

Document number: N3876

Date: 2014-01-19

Convenience Functions to Combine Hash Values

by Nicolai Josuttis

Currently, there is not support in C++ to define hash functions for user-defined keys. Instead, the user has to implement an appropriate function. Implementing a hash function is not trivial. This proposal has the goal to make the definition of hash functions for user-defined types easier by providing a convenience function to combine multiple hash values.

The goal is not to provide a perfect hash function here, but to provide an easy-to-use interface to help application programmers to provide an pretty useful hash function so that they can use hash containers with their types. Note that this does not disable the ability to still provide better user-defined hash tables. It just helps to avoid that a user-defined hash function is better than a naive approach.

Note also that this paper doesn’t provide an easier approach to define new hash functions (as discussed in N333).

Document number: N3875

Date: 2014-01-16

Run-time bound array data members

by J. Daniel Garcia and Xin Li

During the Chicago meeting several options were discussed for Array of Runtime Bounds. These alternatives are well summarized in N3810 [1].

This paper explores into more detail the last option mentioned in N3810 (named there as array constructors). The goal is to provide a general way for dening automatic storage arrays (i.e. stack allocated or side-stack allocated) whose size is not known at compile time.

Document number: N3874

Date: 2014-01-20

Light-Weight Execution Agents

by Torvald Riegel

This paper is an initial attempt at dening light-weight execution agents (EAs), which can be used to run more than one thread of execution but provide weaker forward progress guarantees and/or fewer features than OS threads (see Section 2). From this perspective, threads would be a rather heavy-weigth variant among several kinds of EAs. This work is based on or has been motivated by prior discussions in SG1. It also is at an early stage, so I will conclude by discussing some of the open questions in Section 3.

Document number: N3872

Date: 2014-01-15

A Primer on Scheduling Fork-Join Parallelism with Work Stealing

by Arch Robison

This paper is a primer, not a proposal, on some issues related to implementing fork-join parallelism. It is intended to introduce readers to two key design choices for implementing fork-join parallelism and their impact. Both choices concern how fork-join computations are mapped (scheduled) onto threads. The key point is that the most efficient resolution for these choices is the opposite of what programmers new to parallelism might consider “obvious”. This paper also makes clear that the two choices can be made independently of each other.

The separate subject of how to map fork-join call stacks (“cactus stacks”) onto memory is not covered. Reference [CilkM] surveys various methods for such.

Document number: N3871

Date: 2014-01-19

Proposal to Add Decimal Floating Point Support to C++ (revision 2)

by Dietmar Kühl

This document proposes to add decimal floating point support to the C++ standard. The current version doesn’t spell out the details but instead refers to the Decimal TR (ISO/IEC TR 24733) as a basis and describes changes to be applied to this interface to bring the proposal up to date with C++ 2011 enhancements.