March 2013

New paper: N3559, Proposal for Generic (Polymorphic) Lambda Expressions (Rev. 2) -- F. Vali et al.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3559

Date: 2013-03-17

Proposal for Generic (Polymorphic) Lambda Expressions (Revision 2)

by Faisal Vali, Herb Sutter, Dave Abrahams

Excerpt:

This document revises N3418: Proposal for Generic (Polymorphic) Lambda Expressions and incorporates feedback from the Evolution Working Group (Portland, October 2012). In this revision we propose the two features that received no opposing votes from the EWG (with the other features described in a separate document). Specifically, we propose that auto be required in a lambda-expression's parameter-declaration-clause to identify a generic lambda; and that a generic lambda with no lambda-captures contain a conversion function template to an appropriate pointer-to-function. After a brief discussion of the features (with details deferred to the Appendices), we describe standard wording. All the features proposed in this document have been implemented using clang.

New paper: N3592, Alternative Proposal for Cancellation and Exceptions -- Torvald Riegel

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3592

Date: 2013-03-15

Alternative Proposal for Cancellation and Exceptions

by Torvald Riegel

Excerpts:

In what follows, I will describe cancellation and data escape mechanisms for transactions as specified by the current draft specification and the changes summarized in N3589. These are supposed to replace the cancellation mechanisms in the current draft (i.e., the __transaction_cancel keyword and the cancel-and-throw functionality). ...

The cancellation mechanisms described here are supposed to serve as a foundation for higher-level features that make use of cancellation, such as composable forms of error recovery or more focused kinds of speculative execution. They also try to provide cancellation with no language extensions or changes (besides a minor extension to the syntax of transaction statements); most of the functionality can be expressed as library features. ...

At first sight, it might look like cancellation and exception handling are more or less the same. I disagree with that, and will briefly argue in what follows that they are sufficiently different to justify having separate mechanisms for both. ...

 

New paper: N3591, Summary of Discussions on Explicit Cancellation in Transactional Lang Constructs

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3591

Date: 2013-03-15

Summary of Discussions on Explicit Cancellation in Transactional Language Constructs for C++

by Hans Boehm, Justin Gottschlich, Victor Luchangco, Maged Michael, Mark Moir, Torvald Riegel, Michael Scott, Michael Spear, Tatiana Shpeisman, Michael Wong

Excerpt:

This document summarizes discussions in the SG5 Transactional Memory Study Group on ideas for supporting explicit cancellation of atomic transactions. While we have not reached agreement on whether to support such features or how to do so if we do, we have had some useful discussions that have generated some new ideas and have helped us understand some issues in how we present such features.

New paper: N3589, Summary of Progress Since Portland towards Transactional Language Constructs

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3589

Date: 2013-03-15

Summary of Progress Since Portland towards Transactional Language Constructs for C++

by Hans Boehm, Justin Gottschlich, Victor Luchangco, Maged Michael, Mark Moir, Torvald Riegel, Michael Scott, Michael Spear, Tatiana Shpeisman, Michael Wong

Excerpt:

We restrict attention in this document to issues that we have agreed upon for the next version of the specification, which we are preparing. Other accompanying documents are:

  • Draft Specification of Transactional Language Constructs for C++(v1.1) [1]
  • Summary of discussions on explicit cancellation (N3591) [2]
  • Alternative proposal for cancellation and exceptions (N3592) [3]

New paper: N3564, Resumable Functions -- Niklas Gustafsson et al.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3564

Date: 2013-02-15

Resumable Functions

by Niklas Gustafsson, Deon Brewis, Herb Sutter, Sana Mithani

Excerpt:

While presenting a proposal that can be adopted or rejected in isolation, this document is related to N3558. The reader is advised to read both as a unit and to consider how the two build on each other for synergy. Reading them in their assigned numeric order is strongly advised.

New paper: N3558, A Standardized Representation of Async Operations -- Niklas Gustafsson et al.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3558

Date: 2013-03-15

A Standardized Representation of Asynchronous Operations

by Niklas Gustafsson, Artur Laksberg, Herb Sutter, Sana Mithani

Excerpt:

This proposal is an evolution of the functionality of std::future/std::shared_future. It details additions which can enable wait free compositions of asynchronous operations.

... Target Audience:

  • Programmers wanting to write I/O and compute heavy applications in C++
  • Programmers who demand server side scalability, client side responsiveness, and non-blocking UI threads from applications
  • Programmers who rely on multiple asynchronous operations, each with its own completion event

New paper: N3554, A Parallel Algorithms Library -- NVIDIA, Microsoft, Intel

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Context: In Kona, Redmond, and Portland, Study Group 1 (SG1, Concurrency) discussed language- and library-based ways to add parallelization and vectorization to Standard C++. For Bristol, three participating companies -- NVIDIA, Microsoft, and Intel -- were asked to come up with a combined proposal for a parallel algorithms library as one contribution. This is their first combined paper.

Document number: N3554

Date: 2013-03-15

A Parallel Algorithms Library

by Jared Hoberock et al. (NVIDIA, Microsoft, Intel)

Excerpt:

1 Executive Summary

We introduce a library of algorithms with parallel execution semantics. Some of these algorithms have semantics similar to the existing standard library of sequential algorithms. Some of the algorithms we propose are novel.

We introduce three parallel execution policies for parallel algorithm execution: std::seq, std::par, and std::vec, as well as a facility for vendors to provide non-standard execution policies as extensions. These policy objects may be used to specify how a parallel algorithm should be executed:

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

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

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

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

// vectorized sort
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());

// parallel sort with non-standard implementation-provided execution policies:
std::sort(vectorize_in_this_thread, vec.begin(), vec.end());
std::sort(submit_to_my_thread_pool, vec.begin(), vec.end());
std::sort(execute_on_that_gpu, vec.begin(), vec.end());
std::sort(offload_to_my_fpga, vec.begin(), vec.end());
std::sort(send_this_computation_to_the_cloud, vec.begin(), vec.end());

Algorithms invoked with std::seq execute internally in sequential order in the calling thread.

Algorithms invoked with std::par are permitted to execute internally in an unordered fashion in unspecified threads. It is the caller’s responsibility to ensure that the invocation does not introduce data races or deadlocks.

Algorithms invoked with std::vec are permitted to execute internally in an unordered fashion in unspecified threads. In addition to the restrictions implied by std::par, it is the caller’s responsibility to ensure that a std::vec invocation does not throw exceptions or attempt to perform synchronization operations.

Algorithms invoked without an execution policy execute as if they were invoked with std::seq.

An implementation may provide additional execution policies besides std::seq, std::par, or std::vec.

This proposal is a pure addition to the existing C++ standard library; we do not believe it alters the semantics of any existing functionality.

2 Design Notes and Outstanding Questions

Before introducing the detailed specification of our proposal, we begin by outlining our rationale and by noting that we have identified a number of outstanding questions which require further work to resolve. ...

New paper: N3614, unwinding_exception -- Herb Sutter

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3614

Date: 2013-03-15

unwinding_exception

by Herb Sutter

Excerpt:

This paper does not propose adding language support for D-style scope statements.

Instead, it proposes a new function std::unwinding_exception that returns true iff we are executing a destructor of a stack-based object that is being called to perform stack unwinding.

This enables ScopeGuard and similar uses to automatically and reliably distinguish between success and failure in standard C++ without requiring the user to explicitly signal success or failure by calling a Dismiss function on the guard object.

Meeting C++ 2013 -- Nov 8-9, Düsseldorf, Germany

As C++ heats up, we continue to see new conferences including this one that launched last year. Europe's newest C++ conference is being held again in 2013, with room for 250 attendees and several standards committee members already signed up to speak:

Meeting C++ 2013 Announcement

Information page

Call for Papers (open until May 15)

After last years great success, we will meet again for 2 days full of C++ in Germany this Fall. Meeting C++ 2013 will be again at the 2nd weekend of November (8./9.11.2013). This time the conference will take place at the Lindner Congresshotel in Düsseldorf. For this year there will be 25 Talks and up to 2 keynotes for the 250 attendees at the conference! ...

There will be 3 Tracks about C++ this year, with the 3rd track being a theme track about C++ and UI. ... The other two tracks will offer general C++ talks like last year.

New paper: N3569, Spring 2014 WG21 Meeting Preliminary Information -- Peter Sommerlad

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3569

Date: 2013-03-15

Spring 2014 JTC1/SC22/WG21 C++ Standards Committee Meeting -- Preliminary Information

by Peter Sommerlad

Excerpt (emphasis added):

C++ Standards Committee Meeting

June 16th-21st 2014

The meeting will be held at the University of Applied Sciences, HSR Rapperswil, Switzerland. ...

This paper is preliminary information and we provide it for your convenience and early travel planning. It is important that you make your hotel reservation early, especially if you intend to stay until the end of the meeting, ...

We have made reservations in several nearby hotels (some within walking distance). Please make your reservations by phone, email or fax directly with one of these hotels. Should they be booked please contact us, since there are further opportunities to stay in the vicinity. However, please book early, because there is another larger event going on in Rapperswil towards the end of the week of the meeting.
Also vacation season has already started due to the public holidays around that week.