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.

Document number: N3870

Date: 2014-01-14

Extending make_shared to Support Arrays, Revision 1

by Peter Dimov, Glen Fernandes

This paper proposes adding array support to make_shared, via the syntax make_shared<T[]> and make_shared<T[N]>.

Changes in Revision 1: This revision of N3641 significantly narrows the scope of the proposal, based on feedback from Jeffrey Yasskin and Stephan T. Lavavej. It cuts down the number of make_shared overloads considerably, leaving only two use cases:

— Value initialization, analogous to new U[N]():

template<class T> shared_ptr<T> make_shared(size_t N); // T is U[]
template<class T> shared_ptr<T> make_shared(); // T is U[N]

— Per-element initialization to a specified value, analogous to the std::vector<U>(N, u) constructor:

template<class T> shared_ptr<T> make_shared(size_t N, const U& u); // T is U[]
template<class T> shared_ptr<T> make_shared(const U& u); // T is U[N]

Document number: N3869

Date: 2014-01-12

Extending shared_ptr to Support Arrays, Revision 1

by Peter Dimov

This paper proposes adding array support to shared_ptr, via the syntax shared_ptr<T[]> and shared_ptr<T[N]>.

Changes in Revision 1: Incorporated wording suggestions from Daniel Krügler.

Document number: N3867

Date: 2014-01-19

Specializations and namespaces (Rev. 2)

by Mike Spertus

We propose to allow specializing templates from within a different namespace. The motivation is that when we declare a new class, it is natural to want to provide associated template specializations. For example, it is really painful that whenever I declare a class, I need to class all open namespaces and enter namespace std just to specialize std::hash as shown below ...

The technical point is that the primary template identifies the template's namespace, so we don't need to use the namespace enclosing the specialization's definition to identify it's namespace.

Document number: N3866

Date: 2014-01-19

Invocation type traits (Rev. 2)

by Mike Spertus

We propose a (compiler-supported) type trait std::invocation_type whose type typedef is the implied function type of the callable object when called with the given argument types.

For example, if we define C as

struct C {
  int operator()(double d, int i);
  int operator()(double d1, double d2);
};

then std::invocation_type<C(int, int)>::type would be int(double, int). More precisely the return type of invocation_type<Fn(ArgTypes...)> is result_of<Fn(ArgTypes...)> and each argument type is the same as the formal parameter type matched in the call to Fn. For more detailed information, see the use cases and wording below.

The main difference between this and previous revisions is that we add two variants of the invocation_type.

Document number: N3865

Date: 2014-01-18

More Improvements to std::future

by Vicente J. Botet Escriba

This proposal is an evolution of the functionality of std::future/std::shared_future that complements the proposal "N3784 Improvements to std::future<T> and Related APIs" [3] with more future observers and factories mainly based on the split between futures having a value or a exception.

Document number: N3864

Date: 2014-01-08

A constexpr bitwise operations library for C++

by Matthew Fioravante

This proposal adds support for low level bitwise and logical operations to C++.