Standardization

N4132: Contiguous Iterators -- Jens Maurer

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

Date: 2014-09-10

Contiguous Iterators

by Jens Maurer

Excerpt:

There are four containers in the standard library that guarantee contiguous storage: vector, string, valarray, and array. In the Library Fundamentals TS, there is also string_view. This paper introduces the term "contiguous iterator" as a refinement of random-access iterator, without introducing a corresponding contiguous_iterator_tag, which was found to break code during the Issaquah discussions of Nevin Liber's paper N3884 "Contiguous Iterators: A Refinement of Random Access Iterators". 

C++14 is Ratified: The View from the June 2014 C++ Standard Meeting -- Michael Wong

An update on C++ standardization from Michael Wong, who is here at CppCon this week.

C++14 is Ratified: The View from the June 2014 C++ Standard Meeting

by Michael Wong

From the article:

We had one C++ Standard meeting since my last blog post for Issaquah Standard meeting, and that was in Rapperswil, Switzerland in June 16-21. ...

As I am writing this (which is much delayed due to workload and preparation for airplane time again as I begin my fall business trip after 2 months home working on a special project), I am back in [the Seattle area] to attend CPPCon giving 2 talks, 3 panels, and several interviews....

Trip Report: Red Hat at the ISO C++ Standards Meeting (June 2014)

As we celebrate the approval of C++14 this week, another trip report from the recent ISO C++ meeting:

Red Hat at the ISO C++ Standards Meeting (June 2014): Core and Library

Red Hat at the ISO C++ Standards Meeting (June 2014): Parallelism and Concurrency

From the articles:

Recently Red Hat sent several representatives to the JTC1/SC22/WG21 C++ Standards Committee meetings, which were held in June 2014 at the University of Applied Sciences in Rapperswil, Switzerland...

We have C++14!

C++14 is done!

Following the Issaquah meeting in February, we launched the Draft International Standard (DIS) ballot for the next C++ standard. That ballot closed on Friday.

Today, we received the notification that the ballot was unanimously successful, and therefore we can proceed to publication. We will perform some final editorial tweaks, on the order of fixing a few spelling typos and accidentally dropped words, and then transmit the document to ISO for publication this year as the brand new International Standard ISO/IEC 14882:2014(E) Programming Language C++, a.k.a. C++14.

C++ creator Bjarne Stroustrup writes: "C++14 was delivered on schedule and implementations are already shipping by major suppliers. This is exceptional! It is a boon to people wanting to use C++ as a modern language."

Thanks very much to our tireless C++14 project editor Stefanus DuToit and his helpers, and to all the members of the C++ standards committee, for bringing in this work on time and at high quality with a record low number of issues and corrections in the CD and DIS ballots!

Not only is this the fastest turnaround for a new standard in the history of C++, but as Bjarne noted this is historic in another way: There are already multiple substantially or entirely conforming implementations (modulo bugs) of C++14 available already today or in the near future -- at the same time C++14 is published. That has never happened before for a C++ (or I believe C) standard. For C++98, the delta between publishing the standard and the first fully conforming implementation being available was about 5 years. For C++11, it was two years. For C++14, the two have merged and we have achieved "time on target."

Thanks again, everyone. This was a team effort.

N4131: Another response to N4074; explicit should never be implicit -- Filip Roséen

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

Date: 2014-08-89

Another response to N4074; explicit should never be implicit

by Filip Roséen

Excerpt:

This paper will try to prove why the proposed change of ISO C++ in N4074 shouldn't be allowed using several methods, among them are:

  • Discussions of the, sometimes hidden, implications of such change, and:
  • Arguments regarding how such initialization will differ from the current praxis of C++, and:
  • Proof of Concepts that directly shows why such proposal is not sane.

N4126: Explicitly defaulted comparison operators -- Oleg Smolsky

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

Date: 2014-07-29

Explicitly defaulted comparison operators

by Oleg Smolsky

Excerpt:

N3950 was presented to the Evolution WG at the Rapperswil meeting and the response was very positive. A later revision, N4114 was amended to handle the following points requested at the meeting:

  • Support for non-member operators
  • Mutable members: there was consensus on their treatment. The compromise is to to make explicitly defaulted operators ill-formed when mutable members are present. See "Mutable members".
  • Short-hand notation was proposed and had very positive feedback. See "The proposed syntax: short form".

This proposal makes the following changes after the technical review on the c++std-ext list:

  • Pointer, floating point and enumerated type members are included. See "Domain of the operator functions" for the discussion.
  • Each explicitly defaulted operator is independent and is bridged to the respective members' operators
  • Lexicographical comparison is defined explicitly

N4127: Checked-dereference conditions -- Eelis van der Weegen

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

Date: 2014-07-20

Checked-dereference conditions

by Eelis van der Weegen

Excerpt:

This is a proposal to add a new form of condition...

For example,  if (T x : e) s  translates to  if (auto && __p = e) { T x = *__p; s }  for some invisible name __p.

Translation for the new form of condition in a while or for loop is analogous.

The "next generation" version where the type defaults to auto && is also proposed.