C++ Papers for Chicago: Part 4 - Library, Network, Reflection and C++14

published at 27.09.2013 15:40 by Jens Weller
Save to Instapaper Pocket

This is the fourth and last part of the series, which will finalize the Chicago papers for C++14 and beyond. It was again fun reading all the papers, but a lot less papers this time. While writing those lines C++14 is close to its final ways, it seems that the Chicago Meeting is really getting close to push C++14 out the door. So, in 2014 the ISO and to be precise the national bodies have to finalize C++14, but there will not be any additions or large changes anymore. From today, we know what to expect from C++14. That's great. So, Meeting C++ will be one of the first conferences to discuss the new standard! Looking forward to meet so many of you again :)

For C++14 I've heard (rumors) that dynarray is now part of a TS and not in C++14, and that there could be number separator, to be exact, it's '. But now, lets close this series with the remaining papers, mainly on library, like the last part, but also a few other ones...

N3757 - Support for user-defined exception information and diagnostic information in std::exception

This proposal addresses an issue with exceptions. Exceptions are a bit like goto, once thrown they land somewhere else, but don't pic up information in between. But exactly that could be a very interesting idea, because often crucial information about the error just thrown is burrowed between the point of failure and the point of error handling. The paper wants to add to std::exception the ability, to add information to the exception, before a intermediate handler re-throws the exception. There is no change in the language, just std::exception would need to support this model.

N3758 - Standard exception information types for std::exception

This paper correlates with the previous one. It tries to define standard exception information types to be added to a std::exception before it is re-thrown into the error chain. The proposed types are:

N3759 - SIMD Vector Types

In Bristol there was already a proposal presented for SIMD, which did not succeed, this is a different approach on SIMD. This paper tries to give fundamentals for future SIMD Standardization, one of its proposings is to add *_v types to the standard, where * stands for numeric types in C++ (int,uint,float,double). Further, the paper proposes the introduction of the template simd_vector<T>  utilizing the *_v types. The paper stays with basics for handling SIMD, so follow up proposals could pick up this direction. But it already includes useful examples.

N3761 - Proposing type_at<>

Currently, for achieving what type_at<> could do, std::tuple has to be used. In the context of variadic templates that does not really fit the job, as its usage is more or less abuse. A simple type_at<> template could help to access types in a variadic template easier. The paper also proposes the value_at<> template, extracting not the type but the value used in a variadic template at a certain position.

N3762 - string_view: a non-owning reference to a string

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

N3763 - Traversable arguments for container constructors and methods

This proposal is about Ranges. But as Range as a name is ambiguous, the paper proposes the term traversable instead. It refers to boost::range, but isn't trying to add it yet to the standard, instead it makes a few points, what in the Standard Library has to change, in order to better support traversable Ranges. Such a Range is defined at either being an array or a type able to use std::begin/end. In order to better support traversable types, the Standard Library needs to add additional template constructors/methods taking a traversable type instead of begin and end iterators.

N3764 - Ruminations on relational operators

This paper is about the relational operators in std::optional mainly. The author aims at also adding a std::less specialization for std::optional, which currently doesn't exist.

"This paper proposes to make optional's relational operators do the same thing that tuple and containers do, aka synthesize the operators without using std::less, and in addition to that, add std::less specializations for containers/tuples/optionals holding pointers or std::complex."

N3765 - On Optional

A paper about improvements to std::optional. As the previous paper, it mainly deals with relational operators. Its dealing with similar issues like N3764, but is a little more detailed, and actually contains the code to improve std::optional.

N3766 - The identity type transformation

The SGI implementation of the STL provides an identity functor, which is also in libc++ from clang present:

template
class identity : public unary_function<T, T> {
  T& operator()(T& arg) const { return arg; }  // libstdc++ only?
  const T& operator()(const T& arg) const { return arg; }
};

More recently, also the need for an identity type transformation has risen, such as:

template
class identity {
  typedef T type;
};

Originally, both version could have ended in C++11 as a unified identity template, but were removed in the process of standardization. This paper aims now at adding a template identity_of to type_traits, for supporting identity type transformations, plus adding a identity function object to <functional> to achieve backwards compatibility with SGI.

Network, Range, Reflection and Undefined Behavoir

This now is the last part of this series, covering the 4 papers of the above named subgroups.

N3720 - Working Draft Technical Specification - URI

This is the current draft for adding a URI class to the standard library.

Proposed classes are:

Where uri_error is a strong enum class, the uri class it self refers to its fragments over std::optional<string_view>, the interface is kind of logical (e.g. host, port, query methods). You'll have the great chance to know many more details then just uri at Meeting C++ 2013, as one of the authors speaks at my conference!

N3752 - Index Based Ranges

Only paper from the Ranges subgroup. The goal of this paper is to enable index based ranges, while often "traditional" ranges offer begin/end pairs of iterators, index based access to elements can prevent the use of fat iterators, and hence improve speed. Further the authors conclude that this proposal also could include the support for generator_ranges.

N3728 - Packaging Parameter Packs

This is the only paper on reflection published this year. I think that reflection shares a trait with concepts and modules: Its still a long way till this really will be available as a full implementation. And it looks like that reflection is just starting, this paper starts by dealing with Parameter Packs.

The author clearly states that this is an early version, and not meant yet for standardization, more as a base for discussions and decisions. The goal is to be able to turn a Parameter Pack that is defined f.e. in a variadic template into a typelist, which would make it accessible out side the template. For this purpose the paper suggests the variadic template class parameter_pack, which would contain the pack as a typelist. Further more, the form of <int, foo> shall be a literal parameter pack, which can also be typedef'ed. The greatness of this paper is, that it tries to define a type for typelists, and makes them so (almost) first class citizens of the language without adding to the language. Further more the paper deals with the issue that tuple is a rather poor substitution for a typelist. I hope that this paper evolves into a better future, one thing I'm missing is how this could integrate into a reflection approach, and the author states in the paper that a full version of this paper will be available in the Seattle Meeting in Feb 2014.

N3751 - Object Lifetime, Low-level Programming, and memcpy

There is a subgroup dealing with undefined behavior, this paper is about a certain use of memcpy, which currently is not defined in the standard. The problem with standardization is sometimes, that not everything is defined. And in that case it is undefined behavior, which often depends on the tool chain if the code ends up being correct or more likely not. This example is currently not covered by the standard:

const uint32_t bits = 0x9A99993F;
float x;
std::memcpy(&x, &bits, sizeof x);
float y = x * x;

 The 3rd and forth line are possible sources of undefined behavior:

The paper suggests to allow this behavior, as long as both types have the same size. This would 'legalize' this practice, which the authors claim is a common pattern in low level C++ programming.

The end and more

So, this is the end for the series about papers for the Chicago meeting, which will come to its end tomorrow with a vote on its results. C++14 then will be finalized in 2014, but this weekend will already show a lot of new things and trends. Hopefully the next committee meeting just needs to do some polishing before finally getting C++14 out the door next year. I'm looking forward to the presentations about the ongoing standardization at Meeting C++ 2013, and to see some of you!

Also again, I will post my thoughts on all papers and the state of C++ later to the blog after the series, maybe next week or so.

 

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