intermediate

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.

Find the Bug -- Andrzej KrzemieĊ„ski

Can you spot the bug?

Find the Bug

by Andrzej Krzemieński

From the article:

Today, let's take a short test. Find what is likely to be a bug in the following code and suggest how to fix it.

void Catalogue::populate(vector<string> const& names)
{
  vec_.clear();
  vec_.resize(names.size());

  for (size_t i = 0; i < names.size(); ++i)
    vec_[i] = make_unique<Entry>(names[i]);
}

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

Overload 119 is now available

overload-119.PNGOverload 119 is now available. It contains the following C++-related articles, and more:

 

Overload 119

Feature: Static Polymorphic Named Parameters in C++ -- Martin Moene

Adding parameters to an object can be messy. Here is a description of method chaining -- an interesting way to pass parameters into methods in a more readable fashion.

Capturing Lvalue References in C++11 Lambdas -- Pete Barber

How confusing does it get when references refer to references and references are captured by value? Pete Barber shows us that it all falls out in the C++ consistency wash.

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: Should "property get" functions be noexcept? -- StackOverflow

Quick A: Maybe, but it generally commits you to exposing the internal type (can't change representation).

Recently on SO:

Should I use noexcept for getters always?

Should I use noexcept method modifier for getters always in C++11?

I mean simple getters here that just return members. At least in all my getters I have here an exception can't possibly be thrown. One downside is that a getter gets too verbose:

const std::string& getName() const noexcept{ return name; }

The good side as pointed out in Stroustrup's book is that the compiler might do some optimizations here and there.