C++17 Library Papers for Cologne - Part II

published at 18.02.2015 15:41 by Jens Weller

So, this is the second part about the papers for the Library Working Group Meeting in Cologne next week. The last part already covered some interesting papers, and gives an impression on what will be included into the Standard Library for C++17. This posting contains proposals from the last mailing in 2014 and the first in 2015.

Yet, I want to add, that ofc all this is subject of change, and that some important and interesting things aren't covered in this series. First, everything that is not Library, like concepts and modules for example. Please don't think that this series is about the full view of C++17. For that, you still need the Passierschein a38. Concepts recently has come to the status of Proposed Draft Technical Specification, so its looking very good to have it in C++17. Also, there is interesting work on ranges for C++ happening, but the paper for this is listed as missing, Eric Nieblers recent series of blog posts will give you an excellent insight in (t)his work.

A different development is, that some parts of the standard will only be at the stage of a TS when C++17 needs to be shipped, those parts could be also available as extensions. This years C++ committee Meetings will show, what features will be able to catch the C++17 Train, and which will have to mature inside of a TS for C++2x.

But back to today, which papers will we maybe speak about next week?

The author already coins it pretty well, except this paragraph, its mostly wording for the standard:

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".

Again, mostly wording, and a very good introduction:

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.

Removing clear from string_view.

A very interesting paper and idea. In encryption, not only the code can be used to attack an algorithm, also side channel attacks can build up on system properties, such as power consumption or noise. This is currently not considered in the C++ standard. This paper now wants to add a family of functions to C++, which are "performing common tasks with physical execution properties that do not vary with (specified parts of) the input values.".

The proposed functions equal, copy_conditional and lookup shall operate on the newly introduced std::constant_time::value<T>.

std::array shall have its own make_ function. There already is make_tuple, make_unique, make_pair, make_shared and currently std::array is missing in this club. So why not add this very helpful function the standard?

With C++14 random_shuffle was deprecated, and rand almost too. Its discouraged in C++14, as this paper notes. Since C++11 there is the <random> header in C++, and that is what this replacement is build upon. One of the problems of std::rand is, that it depends on a global state in many implementations. The goals of this paper are:

A direct replacement to the std::rand friends. Despite of the security issues, std::rand is considered both handy and useful as a global uniform random number generator. To expose the most widely-used combo in C++11 <random> without pushing the users to learn the whole design. Smoothing the learning curve can usually optimize the acceptance.

The proposed two functions are randint(from, to) for generating number, and std::reseed for seeding the RNG. The implementation is build upon C++11 <random>.

This paper aims at improving advance, next and prev for iterators, in adding a third parameter for the end iterator:

next(it,end, 3); // 3 is the stepsize, end the end iterator

The goal of this proposal is to add an abs_diff function to the standard, which takes two parameter (unlike abs, which only takes one). The function returns the absolute difference, both parameters need to have support for operator< and operator-.

This paper contains the wording for bool_constant.

Mid-meeting Mailing 2015

Until now, this have been only proposals from the post-urbana mailing in November 2014, now the latest papers from the first mailing of 2015.

This paper is the wording for Multidimensional bounds, index and array_view (in revision 5).

While std::functions operator() is const, it does not invoke the actual function as constant. This leads to the ability to mutate the actual function object, if it has a non-const operator(). This makes std::function in certain corner cases not thread-safe. The proposal aims at making std::function thread-safe for C++17, hence making it illegal to invoke a non-const operator() over std::function. To provide the previous behavior, it is proposed to add an adaptor std::const_unsafe_fun(f).

This seems to only affect code that uses a class with a non-const call operator(), that matches the std::functions signature.

A proposed std::shared_array class is the result of this work. The shared_array class integrates features from shared_ptr, array_view and polymorphic array layout into one interface:

template<class ArrayType, class ArrayLayout = void, class SizeType = size_t> shared_array

Also a weak_array class is proposed, which has a similar role as the proposed array_view.

This proposal would like to make it possible, to release the internal memory of a std::vector just like you can release the pointer inside an unique_ptr today. The motivation of enabling this is, to eliminate a copy of data, when the contents of a vector is handed to a C Library or a different C++ class.

If approved, this should also be added to std::string.

From the paper

This paper addresses the Library Working Group Issue 2228. The crux of this issue is that the converting move assignment operator of unique_ptr will participate in overload resolution, even if the actual implementation of unique_ptr move assignment operator will not compile.

This is an interesting issue, the paper goes on to quote a code example showing the problem. I see this as a current defect in the standard, and this paper fixes this.

std::bitset is currently missing some properties, which other containers (e.g. vector<bool>) have, so when writing generic code, one can't change vector<bool> to bitset, if accessing things like size_type. The paper proposes to

Include a typedef definition size_type for size_t in the class definition. Also all member functions that uses type size_t as the type of a parameter or of the return value should be changed such a way that instead of size_t there would be used the typedef name size_type...

This is AFAIK a breaking change to the standard, but maybe C++17 justifies changes like this.

While std::next and prev have a default value for their second parameter (1), std::advance does not have this. The author wants to change this, so that std::advance also has the default 1.

This is the boost::asio based proposal to add a networking library to the standard. This will be discussed all week at the LWG Meeting in cologne next week:

In the June 2014 committee meeting in Rapperswil, LEWG requested that Boost.Asio-based N2175 Networking Library Proposal for TR2 (Revision 1) be updated for C++14 and brought forward as a proposed Networking Technical Specification. This document is that revision. As well as updating the proposal for C++14, it incorporates improvements to Asio that are based on the widespread field experience accumulated since 2007. The Boost.Asio library, from which this proposal is derived, has been deployed in numerous systems, from large (including internet-facing HTTP servers, instant messaging gateways and financial markets applications) to small (mobile phones and embedded systems). The Asio library supports, or has been ported to, many operating systems including Linux, Mac OS X, Windows (native), Windows Runtime, Solaris, FreeBSD, NetBSD, OpenBSD, HP-UX, Tru64, AIX, iOS, Android, WinCE, Symbian, vxWorks and QNX Neutrino.

Yet, reading this proposal makes clear, that this is a more advanced version of asio, already integrated into a future C++17 standard. Classes like array_view are used. The proposal contains a good overview section, showing lots of example code, and then goes on to provide the needed standards wording, describing a C++ Networking Library for the standard.

From the proposal:

In the original version (N3890) of this paper, we explored the possibility to make all STL containers usable in the recursive data structure definitions, such as struct Entry { std::list<Entry> messages; // ... }; Based on the discussion on the Issaquah meeting, we achieved the consensus to processed with the approach – “Containers of Incomplete Types”, but limit the scope to std::vector , std::list , and std::forward_list , as the first step. The approach itself is well-known shortly after the C++98 standard being shipped [1] , is one of the main features provided by Boost.Container [2] and libstdc++, and is receiving increasing interests in libc++. By limiting the scope, MSVC STL, libstdc++, and libc++ already support the proposed solution.

Nothing to add.

As already described in N4243, a const pointer is still able to invoke a non const method. This proposal wants to add a wrapper class, which prevents this:

The behaviour of const member functions on objects with pointer-like data members is seen to be surprising by many experienced C++ developers. A const member function can call non- const functions on pointer-like data members and will do so by default without use of const_cast . We propose the introduction of a propagate_const wrapper class that propagates const -ness to pointer-like member variables.

The atomic view class provides atomic operations on a non-atomic object. Three different sets of operations are provided, one for any type, one for integral types and one for floating point types. Two classes should be added to the standard:

atomic_array_view

atomic_concurrent_view

The last is meant to be used for legacy code, which cannot be used with atomic<T>, the first for exposing large arrays for HPC.

This proposal aims at adding a helper function std::as_const to <utility>, which would act like a const_cast<const foo&>, but without the syntax overhead. Simply call std::as_const(foo) to receive a const version of foo.

Join the Meeting C++ patreon community!

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