Range Concepts, Part 3 of 4: Introducing Iterables

The third part of Eric Nieblers Series on ranges

Range Concepts, Part 3 of 4: Introducing Iterables

by Eric Niebler

From the Article:

In the last two blog posts, I describes the challenges I’ve encountered while building a next-generation range library. In this post, I’ll sketch for you my proposed solution: refinements of the range concepts that allow delimited, infinite, and pair-o’-iterator-style ranges to fit comfortably within the concept hierarchy without loss of performance or expressive power and with increased safety. I’ve built a range library around these concepts that subsumes and extends all of the C++98 STL algorithms and the Boost.Range adaptors, so I can say with confidence that these concepts lead to a useful and consistent generic range library.

Quick Q: How can I make my constructor take a list of things, like map and vector? -- StackOverflow

Quick A: By having your constructor take an initializer_list<> of the appropriate type.

Today on StackOverflow:

Constructor similar to std::map or std::vector in a class

I'm creating a class and I want to know how to create a constructor similar to the std::map or std::vector style.

std::map<std::string, std::string> map = {
    {"foo", "bar"},
    {"biz", "buz"},
    {"bez", "boz"}
};

The difference is that I don't want my class to ask for types that wants to accept, just like std::map does.

std::map<std::string, std::string>

I want my class to accept that style of arguments:

{
    {"foo", "bar"},
    {"biz", "buz"},
    {"bez", "boz"}
};

But with defined type. (std::string, Typer)

The 'Typer' is a class that I will insert as value on the std::map.

Thank you.

Clang 3.4 and C++14

With the technical completion of C++14 (we think) reported on Monday, we'd like to link to this recent post for your Friday reading pleasure to recap some of the features of C++14.

There are other articles summarizing C++14 features, but some of the short code examples in this one go beyond what we've seen posted elsewhere and are quite interesting. For example, check out primes.

Clang 3.4 and C++14

by Scott Prager

From the article:

With each new release, gcc and clang add on more C++11 and C++14 features. While clang has been behind on some features, though ahead on others, they now claim to have C++1y all worked out...

N3939: Extending make_shared to Support Arrays, Revision 2 -- Peter Dimov, Glen Fernandes

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3939

Date: 2014-02-17

Extending make_shared to Support Arrays, Revision 2

by Peter Dimov and Glen Fernandes

Excerpt:

This paper proposes adding array support to make_shared, via the syntax make_shared<T[]> and make_shared<T[N]>.

This revision of N3870 removes the scalar T&& overloads, reflecting the result of the LEWG review.

Call for Papers for Meeting C++ 2014

Finally I can announce the date and place for Meeting C++ 2014:
We will meet this year in Berlin at the Andels Hotel on the 5th and 6th December!

With the announcement also the call for papers has started, until April 20th you can send in your talks for the conference. This years theme track is "Scientific Programming with C++", I hope to have again a lot of diverse talks about C++ at the conference!

Range Concepts, Part 2 of 4: Infinite Ranges

The second part of Eric Nieblers Series about ranges:

Range Concepts, Part 2 of 4: Infinite Ranges

By Eric Niebler

From the Article:

In the last post, I tried to make delimited ranges fit into the STL and found the result unsatisfying. This time around I’ll be trying the same thing with infinite ranges and will sadly be reaching the same conclusion. But the exercise will point the way toward an uber-Range concept that will subsume delimited ranges, infinite ranges, and STL-ish pair-o’-iterator ranges.

Trip report: Winter ISO C++ meeting

The winter 2014 WG21 (ISO C++) meeting was held in Issaquah, WA, USA on February 10-15. Many thanks to Microsoft for hosting us!

The major work of this meeting was to complete processing of the national body comments received in last summer’s comment ballot for the upcoming C++14 standard. We also began comment processing for the recent corresponding ballot for the File System Technical Specification (TS).

Below are some highlights from this week’s meeting.

C++14: We’re done! (we think)

Some history for perspective:

  • In November 1997, the ISO C++ committee unanimously approved the final text of the first C++ standard. After final ISO balloting, this was published as C++98.
  • In March 2011, we unanimously approved the final text of the second C++ standard, balloted and published later that year as C++11.

On Saturday, we unanimously approved what we believe will be the final text of the third C++ standard, which we expect to become C++14 later this year. This is a huge milestone for C++! And compiler vendors are already scrambling over each other to be the first to ship a fully conforming C++14 implementation -- possibly while the final C++14 ballot is still in progress, which has never happened before.

Note: The upcoming five-month DIS (Draft International Standard) ballot is expected to be the final ISO ballot for C++14. If there are any national objections to the DIS, then there will be one additional FDIS (Final Draft International Standard) ballot stage at the end of this year. However, the national bodies tell me that, barring last-minute surprises, they will likely agree on the DIS contents we just approved on Saturday; in that case the FDIS step will not be required and we would be able to proceed directly to publication later this summer.

For those interested, here are the main (albeit small) changes approved this week as the final set of tweaks for C++14:

I want to say a hearty THANK YOU AGAIN to everyone who has worked so hard, not only on completing C++14, but on bringing it in at such high quality. We had very clean CD ballot with a far lower number of change/bugfix requests than the C++0x/11 ballots, and it’s probably fair to say that today our C++ working paper is in better shape than ever.

Thank you again to everyone on the committee, those who participated via national bodies, and those who gave great feedback and help via the std-discussion and std-proposals groups, for making this possible! This is a really outstanding achievement.

But that’s not all, because we also made progress on other fronts as well...

TS Progress: A lot more is happening

In addition to completing (we hope) C++14, we also made progress on all seven of the TS projects, and approved the creation of one more. Here’s a quick overview of what we accomplished last week, and some notes about what to expect possibly at our next meeting this June in sunny Rapperswil, Switzerland.

The File System TS (GitHub) worked through most of its ballot comments and is expected to complete its ballot resolution in Rapperswil, where we expect to complete the TS and approve sending it out for its final DTS ballot.

The Networking TS material we have so far was approved to instead be added directly to the Library Fundamentals TS (see N3783 below).

The Library Fundamentals TS (GitHub) had a number of additions and is expected to be in shape for its PDTS ballot after Rapperswil. Here is a quick look at what was added to Fundamentals -- follow the links for the details of each paper:

The Array TS working paper was approved, and though we didn’t vote anything more into it at this meeting, LEWG considered additional material that is in good shape to be expected to be added to the Array TS in Rapperswil, including multidimensional array_view and indexes.

The Concepts, Parallelism, and Concurrency TSes had content approved to be turned into initial working papers. Between meetings, the project editors will work on producing formal working papers, which we will consider adopting as TS working papers at the beginning of our next meeting in Rapperswil. One or two of those might even be approved for PDTS ballot following Rapperswil! The initial TS contents are:

Finally, we decided to further expand our workload: We approved asking for a Transactional Memory TS New Work Item (New Project ballot) based on N3919, “Transactional Memory Support for C++.” In Rapperswil we hope to have a paper with wording that we can consider approving to turn into an initial working paper between Rapperswil (June) and Urbana-Champaign (November).

Conclusion

WG21 has now shipped out documents for ballot in the last three consecutive ISO C++ meetings, and the plan is for this to continue. We have been filling up our pipeline, and now we're seeing work come out the other end at a brisk pace.

After the long and "working relatively invisibly" period of C++0x, it's very interesting to see ISO C++ now in a mode where "shipping something out for ISO ballot" is becoming the normal outcome of every meeting. Thanks again to all the volunteers who make it possible! And stay tuned for more to come throughout this year...