Document number: N3747

Date: 2013-09-01

A Universal Model for Asynchronous Operations

by Christopher Kohlhoff

... In this paper, we will first examine how futures can be a poor choice as a fundamental
building block of asynchronous operations in C++. The extended std::future brings
inherent costs that penalise programs, particularly in domains where C++ use is prevalent
due to its low overheads. An asynchronous model based on a pure callback approach, on the
other hand, allows efficient composition of asynchronous operations.

However, cognizant that some C++ programmers may have valid reasons for preferring a
futures-based approach, this paper introduces a universal model for asynchronous
operations. This model supports both lightweight callbacks and futures, allowing the
application programmer to select an approach based on appropriate trade-offs.

Finally, we will see how this universal model can be leveraged to support other models of
composition. This paper presents implementation experience of the universal model, which
includes several pure library implementations of resumable functions, or coroutines.
Programmers have the opportunity to express asynchronous control flow in an imperative
manner, without requiring the addition of new keywords to the language.

Document number: N3746

Date: 2013-08-30

Proposing a C++1Y Swap Operator, v2

by Walter Brown

We propose a new swap operator on native types for incorporation into the C++1Y core language. For user-defined types, we propose that this new operator be treated as a special member function, and that, when viable, its presence provide an alternative to traditional memberwise implementation of defaulted assignment semantics.

Document number: N3745

Date: 2013-08-28

Feature-testing recommendations for C++

by Clark Nelson

[1] The more time that passes without any sort of feature-testing recommendation, the more confusion will affect programmers and implementers interested in features of C++14, of the sort that has plagued C++11 for years. So whatever action should be taken in this arena should not be delayed any more than can be avoided.

[2] SG10 intends to produce its recommendations solely as a WG21 document, without any balloting at higher levels. This is partly to save time, but also to avoid making significant conformance changes. It is hoped that compiler and library implementers will follow these recommendations voluntarily, even without the threat of claims of non-conformance. To improve the chances of that happening, it is considered important to have a record of the endorsement of WG21 -- or at least of the C++ technical experts who attend WG21 meetings.

[3] So SG10 would like to bring this document forward for some sort of approval vote at the Chicago meeting. Formally speaking, no action by the committee is requested, so this vote should probably be just a straw poll.

[4] It should be understood that section 2, “Recommendations” (excluding the sub-sections that are currently stubs), is the section for which approval and stability really matter. Improving the examples, or explanations of rationale, is basically editorial, and improvements will hopfully continue to happen after the recommendations themselves have been approved.

[5] Note that this document recommends that the __has_include feature be provided in the C++14 time frame, even though it is not included in the CD for C++14. A conceivable alternative would be to add __has_include to C++14 before its final publication.

[6] This revision of this document contains STUBS for sections expected to be filled in later.

Document number: N3739

Date: 2013-09-02

Improving pair and tuple, revision 1

by Daniel Krügler

Changes since N3680:

• During a straw-pool vote there was a small majority (4:3) in favour for keeping the two-signatures approach, so this presentation form was used in this revision.
• The original example has been improved.
• The missing application of the declaration pattern to the allocator_arg_t constructors has been fixed.
• Consequent usage of the more precise is_convertible trait instead of the somewhat vague is implicitly convertible description.

Document numbers: N3736-38

Date: 2013-08-27

C++ Standard Evolution Active Issues List (Revision R03)

C++ Standard Evolution Completed Issues List (Revision R03)

C++ Standard Evolution Closed Issues List (Revision R03)

by Ville Voutilainen

The purpose of this document is to record the status of issues which have come before the Evolution Working Group (EWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee. Issues represent potential defects in the ISO/IEC IS 14882:2003(E) document, and proposed extensions to it.

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