C++17 and other future highlights of C++

published at 10.03.2016 11:25 by Jens Weller
Save to Instapaper Pocket

Welcome to the 3rd and last part about current proposals for C++17 and beyond. In the last part, there was an overview on the current Technical Specifications, most likely to move into C++ after C++17. The full proposal listing of 2016 sorted by subgroups contains many more proposals then I can cover.

Last week the C++ Committee met, and discussed C++ Standardization for a whole week. The result is a few new things which got into C++17 and a few major things not going to be in C++17.

Lets have a closer look, last week C++17 gained:

A few intersting things such as constexpr if (aka static_if) have been forwarded to the next meeting in Oulu, Finnland. There are interesting things left, which could make it into C++17 in the next two meetings, last week the committee voted against including concepts into C++17. So, here is the things which are not making it in:

Regarding Concepts, this is a very good summary why it wasn't included. A lot of people think its not yet ready, not mature enough. Its hard to say who is right here, as the main Author of Concepts, Andrew Sutton has a different view, which also sounds valid. Yet I think it is the right decision, to not include something in the standard, that still seems to be so disputed. Also, that concepts does not always improve the error messages and can lead to more difficult to understand errors is interesting.

Modules and Coroutines are not yet in a TS, but should go through one. Which is a good decision, last week is a clear victory for the new standardization process, where all major things have to stay for a some time in a TS, and only then have a chance to be included in the standard. And there is already for all three things at least one implementation as a TS in a major compiler, so things are available if you want to use them.

As it looks like, C++ will focus on a model, where major features get implemented in the major compilers first, and then get standardized with the feedback from that experience. This also means, that there will be no long waiting for implementations, as we had with C++11. So while last week was bad news for C++17 not having concepts, it is an important step for C++ towards a more standardized standardization process: proposals > Technical Specification > Standardization into C++xy.

And ISO Standardization has its disadvantages of being slow, but it is precise. C++ is a multivendor language with several active implementations united by an international standard. Its not owned by a corporation like other languages, and depending on an international standard isn't as flexible as writing something new from scratch.

Future highlights of C++

But lets have a look at the future highlights for C++ in proposal form:

Where is vectorization in C++?

This proposal is a good read for answering the question it asks. With C++17, C++ will have its first bit of vectorization support with the parallel algorithms. The proposal adds to this an overview over the other current plans and proposals for vectorization.

Wording for coroutines

Please note that this a wording paper, hence it will contain lots of standardese. A good overview on coroutines are the talks from CppCon and Meeting C++. This is an important proposal, and it was decided to move it into a TS first, Visual Studio 2015 added support for coroutines, and an implementation for clang is on its way. Coroutines are a mix of a very elegant library solution and adding a few keywords to the standard to invoke this library solution. The compiler is then able to generate the necessary code.

constexpr if

A very interesting paper, and when included in C++17, probably one of its hidden highlights. The author proposes to add the ability to have a constexpr if and else. This would allow to remove a lot of specialization from Template Meta Programming, as one does not have to overload the end of a chain, as its simply now an if condition. The constraints are:

This deals with the main issues why the static_if proposal was not adopted into C++. As far as I understand, unlike a constexpr function, the constexpr if is not available at run time. It is a compile time switch to include only the branches where the condition of the constexpr if expression returns true. This feature might become part of C++17 during the next C++ committee meeting in Oulu in Summer.

Reflection

There seems to be some movement in this field. Three proposals give an overview on where things are heading with C++ & reflection:

The first paper is in its fourth revision, it introduces meta objects, which are the basis for implementing static reflection. These meta objects are to be generated by the compiler, containing basic meta data about a particular object (aka type, variable, namespace, ...). While this is an interesting approach, it also relies on every compiler implementing the meta object generation.

The second proposal wants to add three new instructions, namely typedef, typename and typeid as a template version of t<T,C> which expand to a parameter pack. T is the type, and C is a selector:

where C is a concept, a typename or a template parameter, that provides a boolean constexpr function call operator() template, that will be applied to each element of T, to choose if it will be retrieved or not).

A short example:

namespace ns {
struct X { int x, y; };
}
std::vector< std::string > names{ typeid< ns::X, is_member_object_pointer >... };
std::tuple< typename< ns::X, is_member_object_pointer >... >
mytuple = std::make_tuple(typedef< ns::X, is_member_object_pointer >...);

 The compiler will turn this into the following code:

vector names { "x","y" };
std::tuple< ns::X::int, ns::X::int >
mytuple = std::make_tuple( &ns::some_struct::x, &ns::some_struct::y);

Advantage of this approach is not only are no new keywords needed, no AST control or other things. It is mainly a language solution based on 3 syntax keywords. The paper contains an example as a json serializer. I think this proposal is elegant and a little bit insane at the same time. It is in clear contest with the meta object approach. (it seems that this proposal was at least partly rejected at Jacksonville I hear)

The third paper is an overview and comparision of the current proposals from one of the authors of the second proposal.

I'd say reflection is currently leaving in its early stages, but could move towards a TS in the future (aka 2017), seeing the experience with current standardization, it probably will be a part of the C++ standard in the next decade.

Modules

Do you remember C++Now 2012? I do. There was a keynote on Modules in C++ by Daveed Vandevoorde. Cool, back then clang had an early implementation, a little strange with module files. Last year I learned from Chandler Carruth at Meeting C++ that the motivation behind this was to not touch C++, and not introduce any non standard things in order to support modules. Later, a C++ Standard module version for clang would not need these module files. But back to 2012. Doug Gregor from apple also gave a talk on modules in December 2012 at an llvm meeting.

There is a proposal from 2012 about modules(also from Daveed) which seems to be an overview on how modules could look like, its a follow up to a paper from 2007. So, its been looking pretty good for modules until 2012. I am not sure how strongly connected the proposal and clang implementation are, but the next module proposal is from 2014, coming from Microsoft. This is what is now moving into a TS, and will become part of a future C++ Standard.

There are currently two implementations of modules in C++: MS VS 2015 with the implementation from Gabriel Dos Reis et al. (presented at CppCon 2015) and the older clang implementation. A major difference is, how they treat macros. Clang can export a macro from a module, the newer proposed version can't. You'd have to use a header for making those macros available to a user. Internally macros work ofc in the C++ code of the module. AFAIK this is the main issue in standardization currently, if a module should also export macros or not:

Its a difficult decision if modules should choose to not export/include macros, or if they should be doing exactly this, in order easier adopt for the already existing code base. And I don't want to speculate, what if clang would have made the move to get its implementation into a TS. Whats now happening is, that the committee has to decide what the future of modules is in C++. There is enough implementation experience and with a future TS modules should be available in their final version in all major compilers soon.

SG14 - Games & Low Latency

There is a few proposals from a new subgroup pulling in feedback for C++ from the games industry, but also from other users of low latency C++ such as the financial sector or embedded domain. The proposals cover a wide range of topics, such as input device support, 2d graphics rendering or standardized package managers. This is in its very early stages, and had a public meeting at CppCon last year.

This subgroup has a meeting at GDC next week, please contact Michael Wong if you'd like to join!

Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!

Copyright Meetingcpp GmbH 2024 ImprintPrivacy Policy