Red Hat at the ISO C++ Standards Meeting (November 2014): Library
Last month I attended the ISO standardisation meeting for C++ in Urbana-Champaign. As usual I spent most of the week in the Library Working Group or Library Evolution Working Group. In LWG, about half the week was spent processing comments received from National Bodies during the ballots for the Technical Specification (TS) on C++ Extensions for Parallelism and the TS for C++ Extensions for Library Fundamentals, both of which were at the PDTS (public draft) stage.
LWG reviewed some changes to the Parallelism TS, based on National Body comments, more details of those changes can be found in Torvald’s report.
The Library Fundamentals TS received quite a few National Body comments, some of which were rejected or ruled to be out of scope for the first version of the TS, but some resulted in changes to the draft TS. One significant change to the PDTS was the removal of the generic versions of
htonl due to concerns about implementation difficulty and interference with the C library versions. The other changes to the PDTS are in the post-Urbana mailing as N4270 and N4288. With those changes the Library Fundamentals TS has moved to DTS stage. GCC’s implementations of
string_view will be updated soon to conform to the DTS.
During the rest of the week a number of proposals were reviewed for the next C++ standard (C++17) and for the second version of the Library Fundamentals TS. One issue which has been discussed for some time is how exception specifications should be used in the standard library, but at this meeting we seem to have found a solution that everyone is happy with. Some of the new exception specifications are complex but all the library implementors agree they are correct and can be implemented without problems, and users don’t need to understand the nuances of the spec to benefit from the changes. N4258 has the details of those changes. Many of the edits require all C++ standard library implementations to do exactly what is already done in GCC and the new
is_always_equal trait is based on something originating in GCC, so it will be simple to update libstdc++ to conform to those new requirements.
23 defects reports for the standard library were resolved at this meeting, and during the week we got another 13 ready to be resolved at the next meeting, and agreed on the solution for another dozen or so issues. We still have a large number of unresolved issues, but hope to work on them via email between meetings and to hold two teleconferences for issue processing. I am assigned to draft wording for a few issues, as I either reported them myself or on behalf of GCC users who reported bugs against libstdc++.
The proposal to standardise Boost.Asio as a C++ Networking library is going ahead with strong support from the LEWG, We expect to spend a lot of time reviewing the updated proposal (N4243) more carefully at the next meeting.
For the first time ever we also voted to remove something from the standard library!
std::auto_ptr and a few other deprecated types will not be in C++17, because they have been replaced with alternatives that are either safer or more flexible. Future releases of GCC will warn users when they are using one of those library features that will not be in C++17.
During a busy evening session Eric Niebler presented his work on Ranges. There was widespread support for Eric’s approach and it might form an important part of the next generation of the C++ standard library.
As the Concepts TS is nearing completion (see Jason’s trip report) those involved with that work are starting to think about how to leverage concepts in the standard library. That may have a lot of overlap with the Ranges work, although it’s not yet clear whether they should be combined or kept separate. It would be useful to prototype some of that work in GCC, as has already been done for the Concepts language support.
After the two teleconferences scheduled for December and January the library groups are meeting in Cologne in February, without the rest of the committee. We will work on the backlog of proposals, as well as start serious reviews of the Networking proposal. The next meeting after that will be the full committee one in Kansas in May.
Also, see the related report on core.
Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development. The developer program and software are both free!