Looking for C++17 - Urbana Proposals from Core, Modules, Networking, Reflection and Undefined Behavior

published at 01.11.2014 12:56 by Jens Weller

The second part of my series about the proposals for Urbana, where the next C++ committee meeting will be held. The papers grand us a first view on a distant future - C++17. I also published last weekend an alternative listing of the proposals by mailing and subgroup. And maybe you also want to read the first part about proposals for concurrency.

This time it will be all subgroups with relative few papers combined, evolution and library then will follow with one or two postings each. I might get interrupted by my conference though...

Core

The core working group deals with the language as it self, so its proposals are really a bit special.

From the paper:

This paper proposes to adjust the wording for exceptions to achieve the following goals: Exception specifications as a semantic concept are separated from the grammar term exception-specification

The description of throw-expression is integrated into clause 5. The changes are intended to be editorial only, not changing semantics. Due to the size of the changes, it seems prudent to have a full CWG review for these instead of leaving the issue to the project editor alone.

Not much more to say. Wording only.



From the paper:

This paper presents the proposed resolution for core issue 330 as reviewed in teleconferences of WG21's Core Working Group, substantially cleaning up the wording around qualification converions. Other than allowing the qualification conversions asked for in the issue, it also changes reinterpret_cast so that it may now cast away constness

So, this is another very detailed paper on a very special issue. I guess most people could ignore it, but it shows to what details the committee works on C++. Standardization is just not about adding new features, it is also about keeping the standard valid in a logical and very detailed way.

String-literals have five encoding-prefixes, while character literals only have 4. u8 is the missing one, which this paper seeks to fix, adding u8 as an encoding prefix for character literals. Again, this paper is mostly the changes in wording for the C++ Standard.

This is a first draft of the technical specification about the needed extensions to C++ for making Concepts a reality. Keypoints which will need to be added to C++ for Concepts is adding and defining the new keywords concept and requires. While technical specifications do define what C++17 will look like, they are also because of this nature very detailed and oriented to the standards sections. This makes them not the best read on most of their topics they are trying to standardize, the proposals are often better for human readers. For concepts, I think the best way to be informed is watching Andrew Suttons talk about them from CppCon.

Modules

This is the current state about the plans for integrating modules in C++. The authors name the current 4 goals of such a system:

componentization

isolation of macros

scalable build

support for modern semantic-aware developer tools

The problem for C++ and modules is, that the from C inherited build system takes a different approach, every file is in this model its own translation unit, which is compiled without the knowledge about dependencies to other translation units, this is later resolved by the linker. This is very effective, but also lowlevel. Also, the authors point out, that this linkage model is 40 years old, and with integrating modules in C++, needs to adapted or replaced.

The module system is designed to coexist with the preprocessor, but will not depend on it.

A central tenet of this proposal is that a module system for C++ has to be an evolution of the conventional compilation model. The immediate consequence is that it has to inter-operate with the existing source file inclusion model while solving the significant problems and minimizing those that can’t be completely solved.

A short overview on the planned features for modules:

module and import are new keywords

import is a replacement for include, the named model then gets imported into this translation unit

module module-name; declares a new module, a module has no scope

for scoping namespaces exist. you can only declare one module per translation unit

a module has to use export for its entry points, which form the modules interface

export toplevel-declaration

macros cannot get imported or exported

This would be really cool to have in C++17, and the current proposal could really show a way how a module system for C++ could look like. Yet it will be very interesting to see how this proposal evolves in the coming year.

Networking / Library

This proposal seeks to add a library derived from boost asio to the C++ Standard. New in this revision is that the code has been updated to C++14, by request of the Library Evolution Working Group. The authors refer to boost::asio as the best introduction, but also include an tcp uppercase echo server as an example how a standard asio version would look like. The library has a synchronous and an asynchronous part, which works with handlers, in the examples those are lambdas.

The goal of this proposal is to add support for

udp and tcp sockets, including support for multicast

client and server applications

scalability to handle many concurrent connections

Protocol independence between IPv4 and IPv6

name resolution

timers

to the C++ Standard, out of scope of this document are:

Protocols such as HTTP, FTP, SMTP, but also ICMP

Encryption (SSL/TLS)

OS specific APIs

Reflection

Some applications are designed to never return, so also main is not returning when they are properly run. To prevent the call to destructors registered with atexit, the authors propose to add an optional[[noreturn]] attribute to main. Implementations then can make use of this hint and implement optimizations based on this. The authors also bring into discussion if for this not new versions of main should be added to the standard: void main() without and with arguments.

It has been proposed to add defaulted comparison operators to C++ (N4114/N4175/N4176) by extending the core language, this paper proposes a different solution, to implement defaulted comparison operators using reflection traits, which are proposed in N4113. The authors propose a type trait generate_comparison<T>, which defaults to true, so that the comparison operators get generated, so that you need to specialize it to false to suppress generation. The authors also discuss the opposite, that the default is false, and that you'd have to specialize to true or derive from with_default_comparisons.

The comparison operator is implemented with a default_tie template which enumerates the members of a class into a std::tie function for comparison:

template<class C> auto default_tie(const C& c) {

constexpr size_t n = std::class_member::list_size_v<C>;

return default_tie_impl(c, std::make_index_sequence<n>()); }

This implementation uses the reflection traits from N4113.

Undefined Behavior

There are some issues with the current specification of universal-character-name (UCN), which this paper tries to address. UCNs were introduced to C and C++ to allow internationalization without depending on source text encoding.

The two main goals of this paper are:

to limit or fully remove undefined behavior from the UCN specification

to handle corner cases, which are yet not defined as undefined behavior

This paper deals with preprocessor and undefined behavior. It also updates the specification for the preprocessor to deal with C++11 lexical extensions (e.g raw-strings, user defined literals and new encoding prefixes). It aims at removing undefined behavior further from the preprocessor and adding missing specifications.

Join the Meeting C++ patreon community!

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