New paper: N3525, Polymorphic Allocators -- Pablo Halpern

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: N3525

Date: 2013-03-18

Polymorphic Allocators

by Pablo Halpern

Excerpt:

A significant impediment to effective memory management in C++ has been the inability to use allocators in non-generic contexts. In large software systems, most of the application program consists of non-generic procedural or object-oriented code that is compiled once and linked many times. Allocators in C++, however, have historically relied solely on compile-time polymorphism, and therefore have not been suitable for use in vocabulary types, which are passed through interfaces between separately-compiled modules, because the allocator type necessarily affects the type of the object that uses it. This proposal builds upon the improvements made to allocators in C++11 and describes a set of facilities for runtime polymorphic allocators that interoperate with the existing compile-time polymorphic ones. In addition, this proposal improves the interface and allocation semantics of some of library classes, such as std::function, that use type erasure for allocators.

New paper: N3522, C++ Standard Library Issues List (Revision R82) -- Alisdair Meredith

New WG21 papers are available. Copies are linked below, and 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: N3522, N3523, N3524

Date: 2013-03-18

C++ Standard Library Active Issues List (Revision R82)

C++ Standard Library Defect Report List (Revision R82)

C++ Standard Library Closed Issues List (Revision R82)

by Alisdair Meredith

Excerpt:

The purpose of this document is to record the status of issues which have come before the Library Working Group (LWG) of the INCITS PL22.16 and ISO WG21 C++ Standards Committee.

Quick Q: Why use C varargs when you have initializer_lists and variadic templates? -- StackOverflow

Quick A: No reason, varargs are type-unsafe and entirely superseded by C++11 features (unless you need C compatibility).

Why use variadic arguments now when initializer lists are available?

I've been wondering what are the advantages of variadic arguments over initializer lists. Both offer the same ability -- to pass indefinite number of arguments to a function.

 

What I personally think is initializer lists are a little more elegant. Syntax is less awkward.

Also, it appears that initializer lists have significantly better performance as the number of arguments grows.

 

So what am I missing, besides the possibility to use use variadic arguments in C as well?

New paper: N3560, Proposal for Assorted Extensions to Lambda Expressions -- Faisal 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: N3560

Date: 2013-03-17

Proposal for Assorted Extensions to Lambda Expressions

by Faisal Vali, Herb Sutter, Dave Abrahams

Excerpt:

We propose extensions to lambda expressions motivated by the general view that lambda expressions should allow for a concise and complete description of a callable unit of computation. In addition to containing those features from document N3418: Proposal for Generic (Polymorphic) Lambda Expressions that received against votes in Portland (2012), it also contains other small extensions to lambdas. We also present our experience implementing some of the features using Clang.

... The aim of this paper is to propose various extensions to lambda expressions (generic and non-generic) to simplify and enhance their use. This proposal builds on N3559 (which defines a generic lambda). We assume the reader is familiar with C++11 lambdas and the content of N3559.

It is important to note that not all the authors of this paper are in favor of each and every one of these proposed features and the purpose of this paper is to seek guidance from the EWG regarding which features are worth pursuing further.

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.