Document number: N3729

Date: 2013-09-02

Invocation type traits

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.

Document number: N3728

Date: 2013-09-03

Packaging Parameter Packs (Rev. 2)

by Mike Spertus

The purpose of this paper is to propose mechanisms and rationale for named parameter packs and literal parameter packs. The main idea is to allow parameter packs to be created and named in non-template contexts by allowing parameter pack literals, which are just a template parameter list enclosed in angle brackets. In particular, this proposal makes parameter packs suitable for use as typelists and allows them to be defined and referenced from outside of template classes. While this is not ready for standardization, I want to give and idea of the main ideas and a number of use cases to get feedback from the Reflection working group in Chicago, so a complete proposal can be provided in Seattle.

Document number: N3727

Date: 2013-08-01

A proposal to add invoke function template

by Tomasz Kamiński

The aim of this proposal is to introduce the function template invoke that models INVOKE expression.

Document number: N326x

Date: 2013-09-02

Polymorphic Memory Resources (A Revision of N3525 – Polymorphic Allocators)

by Pablo Halpern

This proposal builds upon the improvements made to allocators in C++11 and describes a set of facilities for runtime polymorphic memory resources that interoperate with the existing compile-time polymorphic allocators. In addition, this proposal improves the interface and allocation semantics of some library classes, such as std::function, that use type erasure for allocators.

Document number: N3725

Date: 2013-08-39

Original Draft Specification of Transactional Language Constructs for C++ Version 1.1 (February 3, 2012)

by M. Wong, A. Adl-Tabatabai, T. Shpeisman, J. Gottschlich

On behalf of IBM Corporation, Intel Corporation and Oracle Corporation, attached please find material entitled "Original Draft Specification of Transactional Language Constructs for C++ Version 1.1 (February 3, 2012)" which is being contributed in connection with the development of ISO, IEC or ISO/IEC publications relating to transactional memory.

Document number: N3724

Date: 2013-08-30

A Parallel Algorithms Library

by J. Hoberock, O. Giroux, V. Grover, H. Sutter, et al.

We propose an extension of the C++ standard library that provides access to parallel execution for a broad range of algorithms. Many of these algorithms correspond with algorithms already in the standard library, while some are novel. Our proposal is a pure extension, as it does not alter the meaning of any existing functionality. Our goal in this proposal is to provide access to the performance benefits of parallelism in a way that (1) can be easily adopted by programmers and (2) can be supported efficiently on the broadest possible range of hardware platforms.

We identify a collection of algorithms that permit efficient parallel implementations. We also introduce the concept of an execution policy, that may be used to specify how these algorithms should be executed. Execution policies become an optional parameter to a standard set of algorithms, permitting the programmer to write code such as the following:

std::vector<int> vec = ...

// previous standard sequential sort
std::sort(vec.begin(), vec.end());

// explicitly sequential sort
std::sort(std::seq, vec.begin(), vec.end());

// permitting parallel execution
std::sort(std::par, vec.begin(), vec.end());

// permitting vectorization as well
std::sort(std::vec, vec.begin(), vec.end());

// sort with dynamically-selected execution
size_t threshold = ...
std::execution_policy exec = std::seq;
if(vec.size() > threshold)
{
    exec = std::par;
}
std::sort(exec, vec.begin(), vec.end());

Interested programmers may experiment with this model of parallelism by accessing our prototype implementation at http://github.com/n3554/n3554.

Document number: N3723

Date: 2013-08-23

Extend operator-> to support rvalues

by Pascal Costanza

We propose the following extension of C++ to enable user-provided definitions for operator-> that support move semantics:

• A user can choose to implement operator-> with an additional parameter of type int. If this definition is called, the parameter will have the value zero. A user can either implement operator-> with or without this additional parameter for a given class. It is invalid to provide both definitions for a given class.
• The return value of operator-> with the additional parameter is a complete class type, and the compiler generates a member access with the dot . operator on that return value instead of using the arrow -> operator.

Document number: N3720

Date: 2013-08-30

Working Draft Technical Specification - URI

by Glyn Matthews, Dean Michael Berris

The scope of this Technical Specification will include a single std::experimental::uri type, specifications about how the are intended to be processed and extended, including some additional helper types and functions. It will include a std::experimental::uri_builder type to build a URI from its components. Finally, it will include types and functions for percent encoding, URI references, reference resolution and URI normalization and comparison.

Document number: N3719

Date: 2013-08-17

Extend INVOKE to support types convertible to target class

by Tomasz Kamiński

This proposal is to extend the definition of INVOKE for class member pointers to cover types convertible to a target class of the pointer, like std::reference_wrapper.

Proposal also resolves LWG issue #2219

Document number: N3718

Date: 2013-08-30

Transactional Memory Support for C++

by Victor Luchangco, Jens Maurer, Mark Moir, et al.

Transactional memory supports a programming style that is intended to facilitate parallel execution with a comparatively gentle learning curve. This document describes a proposal developed by SG5 to introduce transactional constructs into C++ as a Technical Specification. It is based in part on the Draft Specification for Transactional Constructs in C++ (Version 1.1) published by the Transactional Memory Specification Drafting Group in February 2012. This proposal represents a pragmatic basic set of features, and omits or simplifies a number of controversial or complicated features from the Draft Specification. Our goal has been to focus the SG5’s efforts towards a basic set of features that is useful and can support progress towards possible inclusion in the C++ standard. Reflecting this goal, for the first time, we present precise wording changes relative to the Working Draft of the C++ Standard (N3690) to implement this proposal. This document consists of an informal overview of the proposal, several illustrative examples, a summary of some of the discussion in SG5 and the earlier drafting group about design choices, and the above-mentioned wording changes.