C/C++ and Fortran

Originally posted by: Michael_Wong

In part 1 of this trip report, I spoke about the general mood of the April C++ Std meeting in Bristol and the plan to release C++14 Committee Draft (CD) after the meeting. I also deep dived into the language feature set for C++14.

Now I will deep dive onto the library feature additions for C++14. As with the language features, some of these originated from other subgroups. As before, I will not talk about minor bug fixes, but also talk about proposals that did not pass as they are often the most controversial.

• N3545 is an incremental improvement to integral_constant by adding a constexpr operator()

member that returns the value of the template’s data member.

• N3644 adds the ability for null forward iterator to be value initialized and compared as opposed to undefined as they are now.
• N3668 is based on N3511 and N3608 and is another symmetry feature. We allow exchange on atomics and now non-atomics also have them.
• N3658 is based on N3493 and is a proposal to add a type like

template<int...> struct index_sequence { };

so that an instantiation like index_sequence<0, 1, 2, 3> can be passed to a function template that deduces a parameter pack containing the integer sequence 0, 1, 2, 3.

• N3670 is based on N3584 and proposes allowing tuples to be addressed by type as well as by numerical index such as:

tuple<string, string, int> t("foo", "bar", 7);

int i = get<int>(t); // i == 7

int j = get<2>(t); // Equivalent to the above: j == 7

string s = get<string>(t); // Compile-time error. Ambiguous

• N3671 is based on N3607 propose adding overloads for std::equal, std::mismatch, and std::is_permutation to accept two ranges. When using these overloads, the caller does not need to separately check that the two ranges are of the same length. The authors illustrate this using std::equal. For example:

vector<int> v1 = { 1, 4 9 };

vector<int> v2 = { 1, 4, 9, 16, 25, 36, 49 };

vector<int> v3 = { 1, 2, 3, 4 };

assert(!equal(v1.begin(), v1.end(), v2.begin(), v2.end());

• N3656  is based on N3588 and removed dangling memory allocations by adding a useful feature called make_unique which along with make_shared in C++11 means you no longer need to use new and delete, unless you are building low level memory routines. Herb already spoke extensively about the utility of this design in terms of completing C++ safety against dangling memory references.
• N3642 is based on part 1 of  N3531 and adds user-defined literal suffixes for several common facilities including time(h,min,s,ms,us,ns), and string (s) all under their own namespace. String turned out to be controversial as the proposed ‘s’ for string was disliked by some who prefer to reserve that facility for stringview. You see, string is a class in C++ and requires memory allocation and stringview is a new proposed feature that is already supported by several C++ library implementations as the true string, because it is a reference to the actual string. This argument is quite true. In the end, I still felt it was more natural when people think of strings to be associated with ‘s’ despite that it is not truly a string. When stringview does come along we can use something like ‘sv’ and  I don’t feel there is any loss of generality. Note that there is no ambiguity with use of ‘s’ with time because the overloads for such an operator"" s() differ for these two usage scenarios, s can also be used for std::string.
• N3660 is based on the remaining part of N3531 and adds the complex imaginary literal(i, il, i_f) double, long double and float respectively, as a user-defined literal suffix. It was WITHDRAWN before there was a vote on it.
• N3665 is actually an outgrowth of concurrency proposal on synchronizing stream output characters in the presence of multithreading so that they would be sensible. This was NOT PASSED. It is an attempt to allow consistent string output in printf under a limited buffer size. There was a lot of concern this quick fix brought in at the 11^th hour (there was no paper in the pre-meeting email) was disliked on a procedural basis by some, and by others with the concern that it constrained the design space. The supporting argument is that this inconsistency in string output was more serious because C++11 now has threading support. The counter argument is why fix it when it has been around for so long? Personally, I think we should have fixed it as it is a real problem, and most vendors introduce some kind of non-standard locking to ensure consistency.
• N3654 is based on N3570 and is a proposal that is based on Boost.Component to fix the problem that C++ standard library stream I/O for strings that contain embedded spaces can produce unexpected results. For example,

std::stringstream ss;

std::string original = "foolish me";

std::string round_trip;

ss << original;

ss >> round_trip;

std::cout << original;   // outputs: foolish me

std::cout << round_trip; // outputs: foolish

assert(original == round_trip); // assert will fire

The proposed quoted stream I/O manipulator places delimiters, defaulted to double-quote ("), around strings on output, and strips off the delimiters on input. This ensures strings with embedded white space round-trip as desired. For example,

std::stringstream ss;

std::string original = "foolish me";

std::string round_trip;

ss << quoted(original);

ss >> quoted(round_trip);

std::cout << original;     // outputs: foolish me

std::cout << round_trip;   // outputs: foolish me

assert(original == round_trip); // assert will not fire

• N3645 is based on N3586 and is a proposal to address the issues that maps and sets are missing splice operation and that associative/unordered container are missing functions that allows you to extract elements. It DID NOT PASS due to concern about unordered multi set/map versions of these and there are current proposals for multi-threaded versions of these containers which may conflict.
• N3657 is based on N3465 and is a proposal to add heterogeneous comparison look-up to associative containers.
• N3672 is based on N3527 and is the proposal for optional which is a Boost feature. It is a Class template optional<T> that may or may not store a value of type T in its storage space. Its interface allows to query if a value of type T is currently stored, and if so, to access it.  It was a 11^th hour compromise that made it remove all relational operators and only support operator== and operator<. This has proven to be extremely controversial although the motion passed. But I expect a National Body comment with surface to rectify this.
• N3669 is one of those consequential proposal of adding one feature N3652, the subset of N3597 with the removal of const from constexpr member functions which must be carried to the library. Although this was brought in only at the meeting. It is allowed to pass as it updates the library by adding const back now that constexpr has it removed implicitly.
• N3655 is based on N3546 and proposes to augment C++11’s TransformationTraits with a number of template aliases whose use dramatically simplifies the traits’ most common applications.
• N3662 is based on N3532 and is the library version of VLA called dynarray passed. It differs from the language VLA proposal in that it supports zero-sized arrays and can be looked at with decltype. However, both can be implemented on the stack or the heap such that the size is determined at runtime, but cannot change. It was passed amidst some minor concern with dependence and confusion on its relation with the VLA core language proposal.

In Kona, we also approved N3346 Terminolgy for Container Element Requirements while in Portland we approved 2 small papers and a large number of updates to adapt the C++11 library with constexpr.

• N3421 is a proposal to make <functional>'s operator functors easier to use and more generic.
• N3462 deals with the use of result_of in contexts where SFINAE is a consideration; i.e., in function signatures. result_of is intended to be a simple way to compute the result type of some callable when provided with arguments of specified types. It is a shorthand for a longer type computation using decltype and declval. However, there are cases where the use of result_of leads to a hard error whereas the equivalent use of decltype and declval would not. This happens in function signatures, when the direct use of decltype of an ill-formed call expression causes the function to be dropped due to SFINAE. The solution is make result_of SFINAE-friendly by conditioning the presence of the nested type typedef on whether the call expression is ill-formed or not.

• N3302 Constexpr Library Additions: complex, v2

• N3470 Constexpr Library Additions: containers, v2

• N3469 Constexpr Library Additions: chrono, v3

• N3471 Constexpr Library Additions: utilities, v3

This completes the C++14 Library additions. Next I will talk about the new Technical Specifications, Concurrency, and Transactional Memory.