advanced

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.

Range Concepts, Part 1 of 4: Delimited Ranges

The start on a series about ranges from Eric Niebler:

Range Concepts, Part 1 of 4: Delimited Ranges

By Eric Niebler

From the Article:

I’ve been digging into ranges recently, and I’m finding them to be more than just a pair of iterators. In a series of posts, I’ll be expanding the notion of what a range is to cover some kinds of ranges not easily or efficiently expressible within the STL today: delimited ranges and infinite ranges. This post deals with the problems of representing delimited ranges with STL iterators.

C++ Papers for Issaquah - Library, Graphics, Networking, Numerics and Undefined Behavior

This is the last part in the series for Issaquah, and its the most diverse:

C++ Papers for Issaquah - Library, Graphics, Networking, Numerics & Undefined Behavior

by Jens Weller

From the Article:

The 4th and last part about the C++ Papers for Issaquah. I already covered the first batch of proposals from the Library subgroup in the previous part, now its all about papers from Library, Graphics, Networking, Numerics and Undefined Behavior. A very diverse part.

C++ Papers for Issaquah - Library I

The third part of my series about the papers for Issaquah is about the first batch of library proposals

C++ Papers for Issaquah - Library I

by Jens Weller

From the article:

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.

C++ Now 2014 sold out in under a month

cppnow14-soldout.pngAs interest in C++ keeps rising, there are more C++ events but they are also selling out faster. C++ Now 2013, Going Native 2013, and C++ and Beyond 2013 all sold out, some six months before the event.

Now C++ Now 2014 has sold out faster than last year -- this time it sold out in less than a month since registration opened, with over three months left to go.

The good news: You can still register to get on the waiting list, and if you act now there's a good chance you can still get a seat. Each year there will be some number of cancellations, and the organizers expect to be able to take a number of people on the waiting list.

If you have not yet registered for C++ Now 2014 but are interested in potentially going, even if you're not certain yet you should join the waiting list today to get in the queue for a chance to sign up for the last few seats that will open up!

 

If you missed registering for C++ Now and don't make the waiting list, don't despair -- there will be additional major C++ events around the world later this year. Watch for upcoming announcements here on isocpp.org. Stay tuned...

C++ Papers for Issaquah - Concepts, Database and Evolution

This is the second part of my series about the papers for the next C++ committee meeting in Issaquah:

C++ Papers for Issaquah - Concepts, Database & Evolution

by Jens Weller

From the article:

This is the second part about the papers for the C++ committee meeting in February in Issaquah. This time featuring papers from the subgroups of concept, database and evolution. Again, most papers in this series aim for a standard after C++14, most important for C++14 will be the national comments on the new standard. Also there are no new papers from the core working group, only the active issues, defects report and closed issues report are on this mailing.

 

C++ Papers for Issaquah -- Concurrency

So I just started to read through the papers for the next C++ committee meeting in Issaquah in February, first part is about Concurrency:

C++ Papers for Issaquah -- Concurrency

by Jens Weller

From the article:

In february the C++ committee is going to meet for a week in Issaquah, it could be the final Meeting for C++14, the papers in this series will reflect both, C++14 and the standard that will come after it. Currently mostly known as C++1y. A lot of papers that are not part of C++14 will be formed into technical specifications, which some will then become C++1y later. Like the last series, I will again focus on the working groups, and post the papers sorted by the name of the working group, starting with concurrency.

Quick Q: What is this "C++ memory model" you speak of? -- StackOverflow

Quick A: First read Stroustrup's FAQ answer, before reading the SO answers which are also illuminating. For a deep answer and to really grok this topic, check out Sutter's slides from his three-hour deep-dive talk.

A 2011-vintage "new classic" from SO:

C++11 introduced a standardized memory model. What does it mean? And how is it going to affect C++ programming?

... So, what I basically want to know is, C++ programmers used to develop multi-threaded applications even before, so how does it matter if its POSIX threads, or Windows threads, or C++11 threads? What are the benefits? I want to understand the low-level details.

I also get this feeling that the C++11 memory model is somehow related to C++11 multi-threading support, as I often see these two together. If it is, how exactly? Why should they be related?

As I don't know how internals of multi-threading works, and what memory model means in general, please help me understand these concepts. grin

Acquire and Release Fences Don't Work the Way You'd Expect -- Jeff Preshing

The C++11 standard makes a distinction between acquire and release fences and acquire and release operations. The differences are important and can affect correctness as well as performance.

[Ed.: These correctness subtleties are another reason to avoid standalone fences... in addition to the notes in this article, there are performance reasons to do so, as mentioned in Sutter's linked talk. std::atomics are the correct tool in nearly all cases where in the past you'd have reached for a standalone fence.]

Acquire and Release Fences Don't Work the Way You'd Expect

by Jeff Preshing

From the article:

... It's perhaps surprising, then, that this definition does not apply to standalone acquire and release fences in C++11! Those are a whole other ball of wax.

To see what I mean, consider the following two code listings. They’re both taken from my post about the double-checked locking pattern in C++11. The code on the left performs a release operation directly on m_instance, while the code on the right uses a release fence instead. ...