Document number: N3735

Date: 2013-09-02

On the difference between parallel loops and vector loops

by Robert Geva

This is not a proposal, it is a clarification of existing proposals.

Some feedback regarding the loops proposed within the Cilk Plus proposal expressed interest in a loop that is both parallel and vector

Other proposals pursue the idea that an algorithm can be expressed in a way that is independent of whether it is sequential, parallel or vector, and those are chosen as “execution policy”

While all the above are useful and encouraged, this presentation suggests that single threaded vector loops are more foundational and of higher priority than the combined loops and algorithms.

The fundamental argument is that vector loops and parallel loops are mostly very different, whereas their similarities are mostly superficial

Document number: N3734

Date: 2013-09-92

Vector Programming: A proposal for WG21

by Robert Geva

[As] presented to CPLEX within WG14 [ISO C.]

Document number: N3732

Date: 2013-08-30

Value-Oriented Concurrent Unordered Containers

by Arch D. Robison, Anton Potapov, Anton Malakhov

An earlier paper N3425 proposed a design for concurrent unordered associative containers that closely adhered to STL conventions, notably by the way its operations returned iterators that pointed into the container. Doing so raised some issues with concurrent erasure, fears of easy misuse, and generally limited the possibilities for non-blocking implementations to split-ordered lists [1]. Feedback from SG1 was to consider not following STL so closely and consider a value-oriented approach, such as N3533, TBB, and PPL take for concurrent queues. This paper sketches such a design for concurrent maps with intent to elicit feedback.

Document number: N3731

Date: 2013-08-25

Executors and schedulers, revision 2

by Chris Mysen, Niklas Gustafsson

This paper is a proposal for executors, objects that can execute units of work packaged as
function objects, in the form of an abstract base class and several concrete classes that inherit
from it. It is based on components that are heavily used in internal Google and Microsoft code,
with changes to better match the style of the C++ standard.

This proposal discusses the design decisions behind the API and also includes a first draft of
formal wording for the working paper.

Document number: N3730

Date: 2013-08-28

Specializations and namespaces

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

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.