New paper: N3587, For Loop Exit Strategies -- Alan Talbot

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

Date: 2013-03-17

For Loop Exit Strategies

by Alan Talbot

Excerpt:

This proposal suggests an enhancement to for iteration statements to allow the programmer to specify separate blocks of code that execute on completion of a for loop; one for normal termi-nation (when the loop condition is no longer met) and the other for early termination (when the loop is exited with a break). This feature would be especially useful in range-based for statements.

New paper: N3586, Splicing Maps and Sets -- Alan Talbot, Howard Hinnant

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

Date: 2013-03-17

Splicing Maps and Sets

by Alan Talbot, Howard Hinnant

Excerpt:

This is an enhancement to the associative and unordered associative containers to support the manipulation of nodes. It is a pure addition to the Library.

The key to the design is a new function remove which unlinks the selected node from the container (performing the same balancing actions as erase).

New paper: N3585, Iterator-Related Improvements to Containers (Revision 2) -- Alan Talbot

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

Date: 2013-03-17

Iterator-Related Improvements to Containers (Revision 2)

by Alan Talbot

Excerpt:

This proposal recommends several small enhancements to the way containers interact with iterators. While none of these introduces functionality that cannot be achieved by other means, they make containers easier to use and teach, and make user code smaller and easier to read.

New paper: N3584, Wording for Addressing Tuples by Type -- Mike Spertus

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

Date: 2013-03-14

Wording for Addressing Tuples by Type

by Mike Spertus

Excerpt:

In Portland, LWG accepted the "Addressing tuples by type" portion of n3404, pending wording, which is provided below. Note that the "Functoriality" proposal in that paper was not accepted.

New paper: N3582, Return Type Deduction for Normal Functions (Revision 3) -- Jason Merrill

[Ed.: Also of broad interest and on track for near-term standardization.]

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

Date: 2013-03-15

Return Type Deduction for Normal Functions (Revision 3)

by Jason Merrill

Excerpt:

Any C++ user introduced to the C++11 features of auto, lambdas, and trailing return types immediately wonders why they can't just write auto on their function declaration and have the return type deduced. This functionality was proposed previously in N2954, but dropped from C++11 due to time constraints, as the drafting didn't address various questions and concerns that the Core WG had. I have now implemented this functionality in GCC, and propose to add it to C++14. I discuss some of the less obvious aspects of the semantics below.

This proposal also resolves core DRs 975 (lambda return type deduction from multiple return statements) and 1048 (inconsistency between auto and lambda return type deduction).

 

New paper: N3581, Delimited Iterators -- Mike Spertus

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

Date: 2013-03-16

Delimited iterators

by Mike Spertus

Excerpt:

It is extremely tempting to use ostream_iterator to, say, print a vector like:

vector v = {1, 4, 6}; 
cout << "("; 
copy(v.begin(), v.end(), ostream_iterator(cout, ", ")); 
cout << ")"; // Oops! Prints (1, 4, 6, )

The problem is that the “delimiter” in the ostream_iterator constructor call is better described as a suffix than a delimeter.

We offer two alternate proposals.

New paper: N3580, Concepts Lite -- Andrew Sutton, Bjarne Stroustrup, Gabriel Dos Reis

[Ed.: We're calling particular attention to this paper as of broad interest to the community, although still undergoing standardization. This is one of the major papers being considered at the upcoming Bristol standards meeting in April for near-term standardization work.]

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

Date: 2013-03-17

Concepts Lite: Constraining Templates with Predicates

by Andrew Sutton, Bjarne Stroustrup, Gabriel Dos Reis

Excerpt:

In this paper, we introduce template constraints (a.k.a., “concepts lite”), an extension of C++ that allows the use of predicates to constrain template arguments. The proposed feature is minimal, principled, and uncomplicated. Template constraints are applied to enforce the correctness of template use, not the correctness of template definitions. The design of these features is intended to support easy and incremental adoption by users. More precisely, constraints:

  • allow programmers to directly state the requirements of a set of template arguments as part of a template’s interface,
  • support function overloading and class template specialization based on constraints,
  • fundamentally improve diagnostics by checking template arguments in terms of stated intent at the point of use, and
  • do all of this without any runtime overhead or longer compilation times.

This work is implemented as a branch of GCC-4.8 and is available for download at http://concepts.axiomatics.org/˜ans/. The implementation includes a compiler and a modified standard library that includes constraints. Note that, as of the time of writing, all major features described in this report have been implemented.

This paper is organized like this:

  • Tutorial: introduces the basic notions of constraints, shows examples of their use, and gives examples of how to define constraints.
  • Discussion: explains what constrains are not. In particular, we try to outline constraints’s relation to concepts and to dispel some common misconceptions about concepts.
  • User’s guide: provides many more tutorial examples and demonstrate the completeness of the constraints mechanism.
  • Implementation: gives an overview of our GCC compiler support for constraints.
  • Extensions: we discuss how constraints might be extended to interact with other proposed features.
  • Language definition: presents a semi-formal definition of constraints.

New paper: N3579, A type trait for signatures -- Mike Spertus

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

Date: 2013-03-15

A type trait for signatures

by Mike Spertus

Excerpt:

We propose a (compiler-supported) type trait std::signature whose type typedef is the function type of the callable object when called with the given parameter types.

For example, if we define C as

struct C {
  int operator()(double d, int i);
  int operator()(double d1, double d2);
};

then std::signature<C(int, int)>::type would be int(double, double). More precisely the return type of signature<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.

 

New paper: N3571, A Proposal To Add Single Instruction Multiple Data Computation -- P Esterie 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: N3571

Date: 2013-03-15

A Proposal To Add Single Instruction Multiple Data Computation to the Standard Library

by Pierre Esterie, Mathias Gaunard, Joel Falcou

Excerpt:

For maximum accessibility, programmers should be able to vectorize their code without needing a high level of expertise for every single SIMD extension. This proposal introduces a high-level abstraction to the user that gives access to SIMD computation in an instinctive way. It comes as a C++ template library, headers only that relies on a possibly full library implementation. With a high level template type for abstracting a SIMD register, the user can easily introduce SIMD in his application by instantiating this type and applying high level functions on it.

New paper: N3570, Quoted Strings Library Proposal (Revision 1) -- Beman Dawes

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

Date: 2013-03-14

Quoted Strings Library Proposal (Revision 1)

by Beman Dawes

Excerpt:

Character strings enclosed in quotation marks are an element of numerous common data formats (e.g. XML, CSV), yet C++ standard library stream I/O offers no direct support. Furthermore, standard library stream I/O has a problem with embedded spaces in strings that can trip the unwary. The proposed solution provides direct support for quoted strings, avoids embedded spaces problems and is more efficient than likely user provided solutions.

The proposal is suitable for either C++1y or a standard library Technical Specification (TS). It is a pure addition that will break no existing standard-conforming user code. It is based on a Boost component that has been shipping for several years. The declarations for the proposed functions can go in a new header or an existing header.