A look at C++14 and beyond: Papers Part 4

published at 12.04.2013 15:44 by Jens Weller
Save to Instapaper Pocket

This is the 4th and last part about the Pre-Bristol mailing and its papers. This series has given me a good overview, what is up in the future in C++. Still, somethings are missing, not all will come to shine in this series. I have no papers with actual proposals skipped, but a few papers are only to find in the January mailing, and not in this one. One of them is for example a paper on filesystem, which should make it into C++14. How ever, there will be a follow up to this series. At the next meeting of my local C++ User Group we are going to have a video call with Michael Wong and other attendees of the meeting. This will be an interesting chat for sure, and help me refine my view on C++14 and C++17 Standards. I'll write this down in the follow up, featuring also some of the feedback that has come.

Before I start with the last 23 Papers, I'll want to shortly mention where this idea has come from. Last fall I saw two blog entries about the Portland Meeting, each naming a few favorite papers and a short summary of them. One was Japanese, and one was Korean, as far as I remember. I had never seen anything like this in the west, no blog, no site brought anything about the papers. Organizing Meeting C++ did not give me the time, to do something similar back then. The decision to cover all papers came, as I wanted to read through most papers any way, and most papers are worth reading. I'm not yet sure if I do something similar for the Chicago Meeting, as this is very time consuming, and therefore would like to state, that I do look for possible Sponsors helping me doing this.

But, lets get started on some papers...

N3598 - constexpr member functions and implicit const

Last series ended with constexpr, this one starts with it. Again, this could improve constexpr. This paper points to the problem that member functions of constexpr are implicit const. This leads to problems f.e. when implementing literal class types, with the desire of using them inside and outside of constexpr. But, as the paper states this problem only exists for the implicit this parameter of the member function, for details and an example please consult the paper. The paper states 3 different solutions:

N3599 - Literal operator templates for strings

You can now define your own literal suffixes. Also known as UDL - user defined literals. This paper aims at adding an improvement to this, as currently there are no templated versions of the literal operator. One of its use cases could be writing a typesafe printf. While printf is a nice example, the example is far to long to post here. The paper proposes to add

template<typename charT, charT ...String>

to the C++ standard.

N3600 - C++ Latches and Barriers

Some of the commonly used constructs in parallel programming are missing from today's C++ Standard Library. Many of them could be added in a straightforward way. Also, its sometimes more efficient to implement those constructs using atomic-operations and/or lock-free algorithms instead of mutexes. This paper wants to add classes for latches and barriers to the Standard Library.

N3601 - Implicit template parameters

This paper aims to eliminate the need for the redundant template<typename T, class T> idiom. This idiom is widely used, as a web search shows. The authors propose to change the use of template<typename T, class T> C from C<decltype(&X::f),&X::f> to C<&X::f> by using template<using typename T, class T>. The using shall indicate that T shall be deduced. The paper considers some extended examples for this.

N3602 - Template parameter deduction for constructors

The authors propose to extend the template parameter deduction from template functions to constructors for template classes, his would make it possible to write std::tuple t(1,2,3.0) instead of std::tuple<int,int,double>, also make_* functions would not be needed that often.

N3603 - A Three-Class IP Address proposal

There has been a paper, discussing the different solutions for implementing a IP class in a possible networking library for the C++ Standard. This paper now proposes a 3 class solution to this problem. The 3 classes are:

The proposal is based on boost::asio, so this might look familiar to you. N3565 (covered in Part 2) already discusses the different approaches, this paper goes a bit more in the details, why a 3 class approach could be best.

N3604 - Centralized Defensive-Programming support for Narrow Contracts

Long paper about exactly what the title states. The authors conclude to add a new header <preassert> to the standard, containing the support for defensive-programming for narrow contracts. Diving deeper into this topic would require much more than a short description, so I leave it to the reader to dive into the paper.

N3605 - Member initializers and aggregates

This can be seen as a C++11 defect, which this paper aims on fixing. Currently this code is not working due to that if you use member initializers you can't use aggregate initialization:

struct Univ {
    string name;
    int rank;
    string city = "unknown";
};

void t1()
{
    Univ u = {"Columbia",10};
    cout << u.name << ' ' << u.rank << ' ' << u.city << '\n';
}

This paper aims now, at enabling this. However, there is still a discussion about the correct wording for the fix in the standard for this topic going on, details in the paper.

N3606 - Extending std::search to use Additional Search Algorithms

This paper aims at extending the standard library with a search algorithm that takes also the search algorithm as a function object. This lets the standard search be adoptable to special search requirements and would allow for adding additional search algorithms to the standard library:

template<typename Iterator, typename Searcher>
void search(Iterator first, Iterator last, Searcher&& search)

Additionally the paper wants to add to new search algorithms as Searcher classes to the standard library:

The proposal also includes an example implementation of a searcher object.

N3607 - Making non-modifying sequence operations more robust

This paper wants to add a new version of std::equal, std::mis_match and std::is_permutation, which accepts two ranges. Using one of these overloads, the caller does not have to check for matching length of the two ranges.

N3608 - exchange() utility function, revision 2

This paper refers to N3511 and adds a default template argument. Atomic object provide an atomics exchange that sets the new value to the object, and returns the old value. The authors think, that this could not only be useful for atomic objects, and want to add such a function to the standard:

template<typename T, typename U=T>
T exchange(T& obj, U&& new_val) {
  T old_val = std::move(obj);
  obj = std::forward<U>(new_val);
  return old_val;
}

N3609 - string_view - a non-owning reference to a string (revision 3)

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. This paper is a minor revision of N3512, and renames the proposed class to basic_string_view.

N3610 - Generic lambda-capture Initializers - supporting capture-by-move

"C++11 lambdas do not support capture-by-move"

The paper would like to add support for capture-by-move to C++14 lambdas. One example could be moving a unique_ptr into a lambda being executed by a std::future. The authors propose the solution, to allow move-construction:

[x{move(x)}, y, z]

The authors state, that this would be better than to capture by &&x, as this would capture rvalues, but the goal is to capture-by-move.

N3611 - A Rational Number Library for C++

This paper is the 4th version of the proposal to add a rational number library to C++. It reflects the feedback from Portland. The new library shall reside in the new <rational> header.

N3612 - Desiderata of a C++11 Database Interface

This paper aims at giving an overview on the existing Database interfaces for C++ and tries to discuss the needed properties and interfaces for a possible C++ Standard Database interface. The needed features are grouped by the authors into three groups, ranging from high level to low level features.

High level requirements:

Technical requirements:

Implementation requirements:

The paper shows a short use case, and goes on with an overview over the existing solutions for database accesss, which are:

The paper draws no conclusion from this. Still, its a very useful overview and a good collection of requirements for adding database support to C++!

N3613 - "Static If" considered

This paper proves the scenario of implementing static if for C++, and its impact on the language. In the first sentence the authors state, that:

"The static if feature recently proposed for C++ is fundamentally flawed, and its adoption would be a disaster for the language"

Further the authors state, that static if is not compatible to planned features of C++ such as concepts. And therefore could prevent the development of future language features. Also, as static if leads to different branches of code, which only one gets selected at compile time. This adds further complexity to C++ code, and does not make it easier to maintain and understand.

Also the authors find, that the use of static if might become viral, as one would have to check on other places in the code, which branch now is selected. Also, static if uses curly braces ('{'), it does not have its own scope. Still, static if could replace #ifdef and other preprocessor statements, which leads to new problems, as the usage of #ifdef is not going to be ended by static if, also combinations of them will appear.

One might call the authors biased, as they are involved in the work for integrating concepts into C++, still the issues they point out are valid, and therefore must be considered. Concepts, Template constraints and constexpr might be the better way to improve C++ for constraining templates and their use. The authors come to the conclusion, that adding static if to C++ would do more harm then good to the language.

N3614 - unwinding_exception

C++ has std::uncaught_exception(), which returns true, if the thread has an exception thrown that is not yet caught. This paper wants to deal with an issue of std::uncaught_exception by adding unwinding_exception. One of the problems is, that uncaught_exception does not enable the programmer, to test if the current code is part of the stack unwinding happening with the exception. The paper aims at adding std::unwinding_exception() to the standard, which returns true, when called from a destructor of a stack-based object during stack unwinding.

N3615 - Constexpr Variables Templates

This doesn't exist yet. std::numeric_limits is a good example of a work around used for a long time. This proposal wants to add the possibility of compile time calculated constant expression variables (of course as templates) to C++.  Currently the two known work arounds to this are:

Both are work arounds, and could be replaced with this proposal.

N3617 - Lifting overload sets into function objects

This paper aims at allowing function objects and overloaded functions to be more interoperable with function templates. Currently passing a function template or a overloaded function to a generic algorithm (std::for_each f.e.) can be quite cumbersome, and might require casting or wrapping in a lambda. The paper suggests a []function-id syntax, to lift a overload set into a function object, which has no impact on the current standard, as it is currently ill formed.

N3618 - What can signal handlers do? (CWG 1441)

This paper from the core working group asks what signal handlers might do to C++. This paper refers to the CWG Issue 1441:

"CWG Issue 1441 points out that in the process of relaxing the restrictions on asynchronous signal handlers to allow use of atomics, we inadvertently made it impossible to use even local variables of non-volatile, non-atomic type."

The paper proposes a solution to this problem.

N3619 - A proposal to add swapability traits to the standard library

This proposal wants to add two new traits to the C++ Standard:

This would be usefull for writing tempate code, as one could test a type for swap support. Unfortunately is_swappable<T> == true does not mean that std::swap(T a, T b) is well formed, as long as those traits are added on a library level only. The paper discusses possible solutions to this:

N3620 - Network byteorder conversion

The last paper! This one from the networking group discusses conversion of network byte order in a possible Standard implementation. This proposal aims at adding support to the C++ Standard Library for converting between host and network byte order. The following conversion functions are proposed:

The first 4 are to comply with the POSIX Standard. The template versions aim at giving the possibility to extend this functionality by the user. Also there will be added specializations to all common integer types defined by the C++ Standard.

(not) the end

This is the end for the papers of the pre-bristol meeting. The series has been a huge success, and I have gathered much feedback, but also reading all those papers has given me an impression, to where C++ might be heading. This will be more clear after Bristol, but by next week Wednesday, I have the honor to do a video chat to Michael Wong and other Committee members from my local C++ Users Group. After this, I will write a closing entry to this series, expressing my thoughts on C++(11|14|1y) and my reflections on this series.

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