Title: Standards Report

Author: Martin Moene

Date: 04 May 2016 09:40:28 +01:00 or Wed, 04 May 2016 09:40:28 +01:00

Summary: Jonathan Wakely reports from the latest C and C++ meetings.

Body: 

Hello, standards fans! For a change this column includes a first-hand report from the C committee, WG14, as I was able to attend their recent meeting in person. I’ll start with a summary of the last C++ meeting, as that happened first.

The C++ committee met in Jacksonville, Florida, at the start of March. As usual it ran for six days (and nights!) with over 100 people attending. One of the key topics on the agenda was what features are going to be in C++17. As we get closer to 2017 we need to stop adding new features and polish what’s already there, so the evolution working groups decided which proposals should be forwarded for review by the Core and Library working groups at the next meeting. That means we should be getting close to feature complete, and can send out a draft for international ballot later this year.

Some of the big decisions about C++17 content related to the Technical Specifications (TS) that have been published in the last few years, as experimental extensions to C++. At the start of the meeting Herb Sutter asked us to consider five publications for possible inclusion in C++17 (as well as the other proposals worked on during the week), and at the end of the week we decided on each one:

• The Mathematical Special Functions standard, which includes most of the extra maths functions from library TR1 that didn’t get included in C++11. When we discussed this in Lenexa last year there were objections to requiring all implementations to support this, as the functions are not widely used outside of science and engineering, but in the end there was clear consensus for including it in C++17.
• The Parallelism TS, which adds new overloads of most of the algorithms that originally from the STL, allowing them to be executed in parallel (for example using thread pools, or SIMD vector instructions). The committee decided to include these in C++17 as well.
• The first Library Fundamentals TS, which adds lots of utility types including string_view, optional, any, and polymorphic allocators. Most of the TS content will be in C++17, but some parts were left out because they have not yet been implemented anywhere or because they would have introduced incompatible changes to existing pieces of the standard library.
• The Filesystem TS, based on Boost.Filesystem, was also voted into C++17.
• The Concepts TS, which extends the language with one of the biggest changes to happen in C++ recently (see Andrew Sutton’s article in Overload 131 for more detail). There were strong opinions on both sides of the debate, but in the end the consensus was that the specification in the TS is not yet ready for the standard. There are some concerns about having multiple different ways to say the same thing, and that there is only one implementation which hadn’t shipped yet (GCC 6 includes support for concepts and should have been released by the time you read this).

The other big feature which wasn’t approved for inclusion in C++17 is unified call syntax, a proposal to allow f(x, a, b) to be used as an alternative syntax for x.f(a, b). The main objections to the proposal were that it introduced a new kind of overloading as a second-class citizen, and it was felt that it should be better integrated into the existing overloading rules.

The new features which have been approved for C++17 include changes to lambdas so they can be used inside constexpr functions, and a new form of lambda capture to allow capturing *this by value (in C++ today a lambda defined inside a member function can only capture individual member variables by value, or capture them all by reference via capturing this). There are also three new attributes, including one to inform the compiler you really did mean to fall-through a switch case without a break, which means you can ask the compiler to warn you about any fall-through that doesn’t use the attribute. That helps address what I consider one of the biggest flaws in C and C++, that the default behaviour in switch statements is to fall-through rather than to break.

Forwarded from the evolution group to be considered at the next meeting (so likely to be in C++17), are proposals to specify the order of evaluation in expressions (so that function arguments will be evaluated left-to-right), allowing operator-dot to be overloaded, and allowing class template arguments to be deduced from a constructor invocation, so that pair(1, '2') would be equivalent to pair<int, char>(1, '2').

Although the current focus is getting C++17 feature-complete, work also continues on ranges, modules, coroutines, contracts and networking, which are all aiming for their own TS.

So that was C++ in Jacksonville, but in April I also attended the London meeting of the C committee, which was held at the BSI headquarters in Chiswick. Much of the time was spent processing recent defect reports, including several about underspecification of the new multithreading facilities in C11. If you look closely at the C11 standard you’ll notice that it supports recursive mutexes, but doesn’t say anything about how they work! It’s also not clearly stated how mtx_init() behaves if you try to initialize a mutex more than once, or fail to initialize it at all before trying to lock it. Resolving defects like that isn’t too hard, as nearly everyone agrees what the semantics should be, so it’s just a case of writing the wording to specify it clearly and unambiguously.

Another topic of the meeting was the C memory model, based on attempts by Peter Sewell and his group at Cambridge who have been trying to come up with formal models of how the C abstract machine is meant to work according to the standard, and comparing that with how practising programmers think the language works. Among the problems they’ve found when comparing theory and practice are the behaviour of uninitialized data (what the C standard calls ‘unspecified values’), whether there are any guarantees about the values of padding bytes between members of a structure, and the topic of ‘pointer provenance’, which is a similar issue to the object lifetime rules that the C++ committee were considering in Kona last year (see my last column).

The committee also looked at proposals for new features, which might be considered for inclusion in a future C2x revision of the standard. Those included enhancements to what is valid in an integer constant expression (which is much more restrictive in C than in C++, even before the addition of constexpr in C++11), allowing the underlying type of an enumeration to be fixed (a very useful feature, which C++ allows since C++11), and a proposal to add a new __VA_OPT__ feature to the preprocessor, to be used alongside __VA_ARGS__ to solve problems that arise from using empty argument lists with variadic macros. As I’ve mentioned previously in this column, the preprocessor specification is largely the same in C and C++, so that last proposal is being considered jointly by the C and C++ committees, and so the hope is that they’ll both agree on the same change, not two incompatible ones!

It’s interesting to see C thinking about adding things that C++ already has in some form, and the last thing I’ll mention also falls into that category. There is a proposal to add closures to C, based on the Apple ‘Blocks’ extension supported by C and Objective C compilers for Mac OS X and iOS. There is considerable overlap with C++ lambda expressions, but without references, templates, type deduction and other C++ features the proposal for C is necessarily different, especially the syntax. The feature would need non-trivial compiler and runtime support, which is not something typically expected of C compilers, especially those for small embedded systems, so it was no surprise that not everyone on the committee was in favour. The proposal wasn’t rejected though, and so is likely to proceed as a TS.

That’s all for this time, I hope I’ve covered most of the interesting topics. The next C++ meetings will be in Finland, in June, and near Seattle in November. The next C meetings will be in Pittsburgh in October, then Markham, Ontario, next April.

Notes: 

More fields may be available via dynamicdata ..