C++17 Library Papers for Cologne - Part II

published at 18.02.2015 15:41 by Jens Weller
Save to Instapaper Pocket

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?

N4284 - Contiguous Iterators

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

N4285 - Cleanup for exception-specification and throw-expression

Again, mostly wording, and a very good introduction:

This paper proposes to adjust the wording for exceptions to achieve the following goals:

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.

N4288 - Strike string_view::clear from Library Fundamentals

Removing clear from string_view.

N4314 - Data-Invariant Functions

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

N4315 - make_array, rev. 3

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?

N4316 - std::rand replacement

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:

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

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

N4317 - New safter functions to advance interators

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

N4318 - Proposal to add an absolute difference function to the C++ Standard Library

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

N4334 - Wording for bool_constant

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.

N4346 - Multidimensional bounds, index and array_view, revision 5

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

N4348 - Making std::function thread-safe

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.

N4355 - Shared Multidimensional Arrays with Polymorphic Layout

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.

N4359 - A Proposal to Add vector release method just like unique_ptr release method to the Standard Library

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.

N4366 - LWG 2228: Missing SFINAE rule in unique_ptr templated assignment

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.

N4368 - Introducing alias size_type for type size_t in class std::bitset

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.

N4369 - Default argument for second parameter of std::advance

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.

N4370 - Networking Library Proposal (Revision 4)

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.

N4371 - Minimal incomplete type support for standard containers, revision 2

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.

N4372 - A Proposal to Add a Const-Propagating Wrapper to the Standard Library

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.

N4373 - Atomic View

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:

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.

N4380 - Constant View: A proposal for a std::as_const helper function template

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!

Copyright Meetingcpp GmbH 2024 ImprintPrivacy Policy