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

By Blog Staff | Mar 19, 2013 10:52 AM | Tags: intermediate experimental

[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

By Blog Staff | Mar 19, 2013 10:47 AM | Tags: None

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.

By Blog Staff | Mar 19, 2013 10:42 AM | Tags: None

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

By Blog Staff | Mar 19, 2013 10:40 AM | Tags: None

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.

 

New paper: N3565, IP Address Design Constraints -- Aleksandar Fabijanic

By Blog Staff | Mar 19, 2013 10:38 AM | Tags: None

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

Date: 2013-03-15

IP Address Design Constraints

by Aleksandar Fabijanic

Excerpt:

This is a summary of IP address class design constraints that surfaced during Portland SG4 meeting [PORTLD] and subsequent [CPPSTDN] discussions. Goal is to determine a direction for the standard C++ IP address class proposal. This document does not aim to be a final verdict on what the design of standard IP address classes should look like; rather, it summarizes the concerns raised in discussions so far, weighing pros and cons of each proposed design. It is meant to serve as a reference for SG4 IP address discussion during Bristol meeting in April 2013.

New paper: N3563, C++ Mapreduce -- Chris Mysen, Lawrence Crowl, Adam Berkan

By Blog Staff | Mar 19, 2013 10:35 AM | Tags: None

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

Date: 2013-03-15

C++ Mapreduce

by Chris Mysen, Lawrence Crowl, Adam Berkan

Excerpt:

For large scale distributed problems, the map-reduce framework has proven to be a highly effective way at creating highly parallel workflows working over distributed filesystems on petabyte scale operations and has been used for analysis, machine learning, and implementation of many distributed computation problems at Google.

This proposal outlines the details of a version of mapreduce which is logically simple but very extensible, based heavily off of both distributed and threaded versions of mapreduce, allowing for implementations which work as distributed, threaded, or both. There are some simplifications in this implementation which are detailed later, but much of the flexibility of many of the implemented map-reduces is retained.

New paper: N3562, Executors and schedulers, revision 1 -- Matt Austern et al.

By Blog Staff | Mar 19, 2013 10:32 AM | Tags: None

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

Date: 2013-03-15

Executors and schedulers, revision 1

by Matt Austern, Lawrence Crowl, Chandler Carruth, Niklas Gustafsson, Chris Mysen, Jeffrey Yasskin

Excerpt:

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.

New paper: N3561, Semantics of Vector Loops -- Robert Geva, Clark Nelson

By Blog Staff | Mar 19, 2013 10:27 AM | Tags: None

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

Date: 2013-03-15

Semantics of Vector Loops

by Robert Geva, Clark Nelson

Excerpt:

In the SG1 conference call on Feb 5 2013, I presented the topic of a critical section in a vector loop. The discussion on the narrow topic itself resulted in the consensus that a critical section in a vector loops is undefined behavior. However, the discussion also led to broader interest in the semantics of a vector loop, which I was asked to present. This paper describes the semantics we propose. Note that this paper is meant as a continuation of earlier papers on vector loops, and is probably not self-contained. It does not repeat the syntax and language rules portions of the proposal.

As was stated in earlier meetings, this proposal is an attempt to codify existing practice in vector programming. While in a narrow sense, there are no existing practices of vector programming within standard C++, vector programming is broadly used in ad hoc ways. The expectations of programmers are well understood. The proposal here is not to invent new programming models. Instead, it is an attempt to codify the existing expectations of existing practitioners using C++ methodology.

New paper: N3557, Considering a Fork-Join Parallelism Library -- Pablo Halpern

By Blog Staff | Mar 19, 2013 10:25 AM | Tags: None

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

Date: 2013-03-18

Considering a Fork-Join Parallelism Library

by Pablo Halpern

Excerpt:

There is general consensus in the Concurrency and Parallelism study group (SG1) that strict fork-join parallelism would be a desirable feature to add to C++. They asked me to research whether it is possible to create a pure library interface for strict fork-join parallelism that achieves the same benefits as the well-established keyword-based language interface pioneered by the Cilk project and proposed for standardization in N3409. The technical and aesthetic advantages offered by the language approach include simple syntax, appropriate lifetimes for arguments in asynchronous function calls, correct overload resolution for asynchronous function calls, clear and enforceable strictness, and correct exception handling. This paper describes the challenges of creating a comparable library interface and explores the possibility of making small, general-purpose, language changes to enable a library solution to overcome those challenges. Ultimately, however, the library interface shows significant weaknesses when integrating with core features such as object lifetimes and exception scope. The library interface in particular is susceptible to misuses which may introduce subtle problems into programs that would be hard for many programmers to diagnose. Since our goal is making parallel programming accessible to the widest possible range of programmers I question whether a library approach could ever achieve this goal.

New paper: N3556, Thread-Local Storage in X-Parallel Computations -- P Halpern and C E Leiserson

By Blog Staff | Mar 19, 2013 10:21 AM | Tags: None

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

Date: 2013-03-18

Thread-Local Storage in X-Parallel Computations

by Pablo Halpern, Charles E. Leiserson

Excerpt:

... [W]e designate the model under discussion as being an X-parallel model, where X might represent a variety of individual parallelization technologies, including vector units, GPU’s, task-based multithreading, attached processing, and the like. ...

The purpose of this paper is to develop terminology so that the impact of any X-parallel model on TLS can be described clearly and evaluated effectively. We compare the semantics of accessing a TLS variable within an X-parallel region to the semantics of accessing the same variable in serial execution. We propose a 5-level hierarchical taxonomy of TLS concordance, where each level in the hierarchy is more faithful to the way the existing threading model treats TLS than the level below. Placing an X-parallel model lower within the taxonomy does not necessarily mean that it is a bad model, but lower in the hierarchy does mean that an X-parallel model is a less faithful extension to the existing standard than a higher-level model, at least as far as its adherence to legacy TLS behavior is concerned.

We conclude with a brief discussion in which we advocate that any X-parallel model should provide Level-5 (full) concordance — the highest level — unless there is a compelling reason to the contrary.