Standardization

New paper: N3538, Pass by Const Reference or Value -- Lawrence Crowl

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3538

Date: 2013-03-06

Pass by Const Reference or Value

by Lawrence Crowl

Excerpt:

Efficiency and expressiveness are hallmarks of C++, but sometimes those hallmarks conflict in ways that force programmers to compromise on one or the other. The progammer's choice of passing a given argument by const reference or by value is one of those compromises. That compromise has become more of a problem with modern calling conventions.

In this paper, we describe the problem, discuss possible approaches to reduce the problem, and explore a solution that introduces a new language feature...

New paper: N3535, C++ Stream Mutexes -- Lawrence Crowl

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3535

Date: 2013-03-06

C++ Stream Mutexes

by Lawrence Crowl

Excerpt:

At present, stream output operations guarantee that they will not produce race conditions, but do not guarantee that the effect will be sensible. Some form of external synchronization is required. Unfortunately, without a standard mechanism for synchronizing, independently developed software will be unable to synchronize.

 

This paper proposes a standard mechanism for locking streams...

New paper: N3531, User-defined Literals for Standard Library Types -- Peter Sommerlad

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3531

Date: 2013-03-08

User-defined Literals for Standard Library Types (version 3)

by Peter Sommerlad

Excerpt:

The standard library is lacking pre-de fined user-defi ned literals, even though the standard reserves names not starting with an underscore for it. Even the sequence of papers that introduced UDL to the standard contained useful examples of suffixes for creating values of standard types such as s for std::string, h for std::chrono::hours and i for imaginary parts of complex numbers.

Discussion on the reflector in May 2012 and in Portland Oct 2012 showed demand for some or even many pre-de fined UDL operators in the standard library...

New page: Papers and Mailings

There's a new page under Standardization -> Meetings and Participation that answers common questions about "what are papers and mailings all about?"

Papers and Mailings

This is timely information, because the pre-meeting mailing deadline is just a week away -- next Friday, March 15.

We'll continue to expand this and other standardization information to answer frequently asked questions and keep it current.

 

New paper: N3536, C++ Sized Deallocation -- Lawrence Crowl

A new WG21 paper is available:

Document number: N3536

Date: 2013-03-05

C++ Sized Deallocation

by Lawrence Crowl

 

Excerpt:

Problem

With C++11, programmers may define a static member function operator delete that takes a size parameter indicating the size of the object to be deleted. The equivalent global operator delete is not available. This omission has unfortunate performance consequences.

Modern memory allocators often allocate in size categories, and, for space efficiency reasons, do not store the size of the object near the object. Deallocation then requires searching for the size category store that contains the object. This search can be expensive, particularly as the search data structures are often not in memory caches.

Solution

Permit implementations and programmers to define sized versions of the global operator delete. The compiler shall call the sized version in preference to the unsized version when the sized version is available.
...

New paper: N3526, Uniform initialization for arrays and class aggregate types -- Michael Price

A new WG21 paper is available:

Document number: N3526

Date: 2013-01-21

Uniform initialization for arrays and class aggregate types

 

by Michael Price

An excerpt:

This document proposes a slight relaxation of the rules for eliding braces from aggregate initialization in order to make initialization of arrays and class aggregates more uniform. This change is required in order to support class aggregate types with a single member subaggregate that behave similarly to their array counterparts (i.e. std::array).

[...]

However, when we begin to mix the aggregate types, uniform initialization begins to break down.

  struct aggr_t {
      int a;
      int b;
  }  array_of_aggr[2] = {{1, 2}, {3, 4}};

  struct aggr_ex_t {
      int x[2][2];
  };

  aggr_ex_t bad  = {{1, 2}, {3, 4}};      // Error: Too many initializers, see below for details
  aggr_ex_t good = {{{1, 2}, {3, 4}}};

Concepts Lite: Constraining Templates with Predicates -- Andrew Sutton, Bjarne Stroustrup

During the C++11 standards development cycle, much work was done on a feature called "concepts" which aimed at providing systematic constraints on templates. Concepts was deferred from C++11 for lack of time to complete it, but work has continued.

In January 2012, the results of a major "concepts summit" were published as a 133-page report titled "A Concept Design for the STL" (WG21 paper N3351).

Now, a draft of new paper is available proposing a very useful subset of concepts, dubbed "Concepts Lite", for near-term consideration including at the spring ISO C++ meeting in Bristol, UK, this April. For example, imagine writing this template:

template<Sortable Cont>
void sort(Cont& container);

and when you call it like this:

list<int> lst = ...;   // oops, bidirectional iterators
sort(lst);             // today, results in very long "template spew" error message

getting this short and non-cryptic error message:

error: no matching function for call to ‘sort(list<int>&)’
   sort(l);
         ^
note: candidate is:
note: template<Sortable T> void sort(T)
   void sort(T t) { }
        ^
note: template constraints not satisfied because
note:   'T' is not a/an 'Sortable' type [with T = list<int>] since
note:     'declval<T>()[n]' is not valid syntax

That's an actual error message from the prototype GCC implementation linked below.

We're very excited about this feature and its continued progress. Here are links to the draft of the new paper:

Concepts Lite: Constraining Templates with Predicates (PDF) (Google Docs)

From the Introduction:

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.

Related links:

New forum active: SG8 (Concepts)

A new publicly readable committee forum is now available on the Forums page:

SG8 : Concepts

Near-term focus is on a convergence between the static if proposals and the parameter-type-constraints subset of concepts.

Note that this forum is for standardization of a new feature; do not expect the features mentioned in this forum to be available yet in your own compiler. However, if you're interested in seeing the shape of the feature as it advances to being approved by the committee likely in the near future, this forum is for you.

For information about this and other SGs, see also: