C++ Papers for Issaquah - Library I

published at 11.02.2014 12:53 by Jens Weller
Save to Instapaper Pocket

The 3rd part of the C++ papers for Issaquah series will be about the library proposals. The last part covered the papers from concepts, database and evolution. There are a lot of proposals from the library group, and I think some of them are the most interesting, as they don't have any impact on the core language. Like last time I'm going to split the library proposals into 2 parts. Also you might want to take a look at the library proposals from the fall meeting in chicago.

N3829 - apply() call a function with arguments from a tuple (V2)

The idea of this proposal is to add a apply function for std::tuple. The apply function would unpack a tuple and use the tuple items as arguments in a function call. The proposed function would look like this:

template <typename F, typename Tuple>
decltype(auto) apply(F&& f, Tuple&& t);

As an alternative there could be an operator... to unpack tuples and template parameter packs as a language extension. The author states that such an operator... has not yet been proposed, and even if, it would be unclear if it would be part of C++17. So apply could fill this role without changing the core language.

N3830 - Scoped Resource - Generic RAII Wrapper for the Standard Library

C++11 already introduced unique_ptr (and shared_ptr) as a way to handle resources. This proposal aims for a new RAII like class to manage zero or more resources on the stack. This class should behave like unique_ptr, it would also be movable, able to release its resource(s) and handle destruction when the stack is destroyed. The proposed class is only possible through some features of C++14, as Peter Sommerlad demonstrated in the Chicago meeting.

So in essence:

"This proposal introduces a new RAII "smart" container called scoped_resource which can bind a resource to "clean-up" code regardless of type or the number of arguments required by the "clean-up" function."

While unique_ptr could fill this role, one of the problems with this would be, that unique_ptr is build for pointers, but not all resource types are pointers. For example some windows APIs work with HANDLE. An invalid HANDLE does not have to be nullptr. The authors conclude, that a std::scoped_resource(closehandler,handle, unvalidhandle-value) could solve this problem, and allow a better management of resources in C++.

N3840 - A Proposal for the World's Dumbest Smart Pointer, v3

C++11 brought std::shared_ptr and unique_ptr to the standard, and deprecated C++03 auto_ptr. This proposal aims at adding a 3rd smart pointer type, only providing very basic functionality. And very basic means, the pointer isn't owning the object its pointing to. Its only providing the interface of a pointer type, but does not know how to manage it. This class could replace a raw pointer, only used to access or point to an object.

The paper proposes the name observer_ptr for this kind of type, but also lists various other possible names. An alternative would be to define a unique_ptr with a non-deleting deleter. But the semantics of a unique_ptr are quite different from an non-owning pointer type. While unique_ptr is only moveable, a non-owning pointer type should be also copyable and movable.

N3841 - Discouraging rand() in C++14

As the title suggests, this paper aims for C++14. With C++11, C++ offers with <random> more randomness then just the plain old rand/srand functions originating from C. This proposal provides the wording for deprecating random_shuffle and to encourage users of rand to migrate to <random>.

N3842 - A sample Proposal

Previously in N2569 some additional algorithms where suggested for adding to the STL, including random_sample and random_sample_n, which are also part of the SGI implementation of SGI. This proposal now aims at adding these 2 functions to the C++ standard, but as a single interface sample function. The interface of sample selects the correct function to call by the iterator type (tag based) of its argument.

N3843 - A SFINAE-Friendly std::common_type

In 2012 at the portland meeting there was a proposal accepted for C++14 which makes result_of more SFINAE friendly. This proposal now is doing similar for std::common_type.

N3844 - A SFINAE-Friendly std::iterator_traits

In 2012 at the portland meeting there was a proposal accepted for C++14 which makes result_of more SFINAE friendly. This proposal now is doing similar for std::iterator_traits.

N3845 - Greatest Common Divisor and Least Common Multiple

Abstract from the paper:

This paper proposes two frequently-used classical numeric algorithms, gcd and lcm , for header <cstdlib>. The former calculates the greatest common divisor of two integer values, while the latter calculates their least common multiple. Both functions are already typically provided in behind-the-scenes support of the standard library’s <ratio> and <chrono> headers.

Describes it pretty well :) Would be nice if this could be added to the library.

N3847 - Random Number Generation is Not Simple!

This paper deals with correct (pseudo) random number generation in C++11 and C++14 through the C++ Standard library <random> header. The proposal goes on with several options on how to add and improve interfaces for random number generation to the C++ standard library.

N3849 - string_view: a non-owning reference to a string, revision 6

This paper wants to introduce a new class to the Standard Library, acting as a non owning reference to a string. For this three implementations exist, which are unified for the proposal, the already existing implementations are from Google (Chromium), Bloomberg and LLVM. A string_view can be constructed from std::string or const char*, and has most of the const methods of std::string.

Some papers come a long way, so this is revision six of the proposal for string_view. The idea is, to have a class representing a range or in this case a view of a string somewhere else in memory. As the title suggests, string_view does not own the memory it points to. The string_view class shall have the const interface of std::string, one of the many use cases of such a class would be working with textfiles, XML or HTML tags could be presented as views instead of strings owning additional memory f.e.

N3854 - Variable Templates For Type Traits

This proposal aims at C++17, as variable templates are part of the C++14 standard, they should be used in type traits. This would result into writing is_same_v<T,U> instead of is_same<T,U>::value. boost has in its tr1 implementation already done similar by replacing decay<T>::type with decay_t<T>.

N3856 - Unforgetting standard functions min/max as constexpr

I think this the shortest proposal I've ever seen. Its about making std::min & std::max constexpr functions. In one page.

N3862 - Towards a Transaction-safe C++ Standard Library: std::list

This paper is a proof of concept, that transactional memory can be easily supported in the standard library. As a first example the authors picked to enhance std::list with transactional language features. This was done with a trunk-version of GCC 4.9 and its support for transactional memory. Future goals are to add transactional language constructs to more standard containers and also to enable clang support through the llvm C++ library implementation.

N3866 - Invocation type traits (Rev. 2)

Adding a new type trait for invocation types is the aim of this paper. The proposed std::invocation_type contains a typedef type is the implied function type of the callable object when called with the given argument types. For example this could help with perfect forwarding, the paper uses an implementation of async as an example.

N3869 - Extending shared_ptr to Support Arrays, Revision 1

I've blogged earlier this year about smart pointers. One difference between std::shared_ptr and boost::shared_ptr currently is, that the boost implementation also supports array types (since 1.53), This proposal wants to add this also to std::shared_ptr. Enabling the following use cases:

std::shared_ptr<T[]>
std::shared_ptr<T[N]

Currently this can already achieved by holding pointers to arrays and having a custom deleter. So most of the needed support for this feature is already there, with only a few changes to std::shared_ptr this could be enabled "out of the box". And boost already has done this successfully including tests and documentation. Also, std::unique_ptr is already able to this, plus alternatives like std::vector and std::array exist.

N3870 - Extending make_shared to Support Arrays, Revision 1

This proposal accompanies the previous proposal to add array support to std::shared_ptr. But it deals with the needed changes to make_shared when the support for arrays is added. Again, this is already implemented in boost. There would be 4 new versions of make_shared:

// value initialization, like new U[N]()
template<class T> shared_ptr<T> make_shared(size_t N); // T is U[]
template<class T> shared_ptr<T> make_shared(); // T is U[N]
// Per-element initialization to a specified value, analogous to the std::vector<U>(N, u) constructor

template<class T> shared_ptr<T> make_shared(size_t N, const U& u); // T is U[]
template<class T> shared_ptr<T> make_shared(const U& u); // T is U[N]

When using shared_ptr, make_shared should be the preferred way to create a shared_ptr. So, when making changes to shared_ptr, also make_shared needs to be updated.

This is the end of the 3 Part about the Library Proposals, in the 4th part of this series is about more proposals from Library plus Graphics, Networking, Numerics and Undefined Behavior.

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