Scott Meyers in Oslo: Friday, June 14

On Friday, June 14, Scott Meyers will be giving a talk open to the public at the Oslo C++ Users Group.

From Scott's announcement:

Lambdas vs. std::bind in C++11 and C++14

Scott Meyers

 

C++ developers have long had a need to bind functions and arguments together for a later call. This is what makes it possible to invoke member functions on objects inside STL algorithms. The same technology can be used to create custom callback functions and to adapt function interfaces to different calling contexts.

In C++98, such binding was accomplished via std::bind1st and std::bind2nd. TR1 added std::tr1::bind, which was promoted to std::bind in C++11. But C++11 also introduced lambda expressions, and they’re slated to become even more powerful in C++14. That means that there are now two mechanisms in C++ for binding functions to arguments for later calls: std::bind and lambda expressions. In this talk, Scott examines the pros and cons of each approach, comparing them in terms of expressiveness, clarity, and efficiency, and he comes to the conclusion that one should almost always be used instead of the other. But which one?

 

This presentation assumes a basic familiarity with std::bind and C++11 lambda expressions.

Quick Q: Should I return a const value? -- StackOverflow

Quick A: No.

Some authors wrote "Consider doing this" in C++98. The answer is now a definite "No" because it prevents move from returned values.

Isn't the const modifier here unnecessary?

The "Effective C++" Item 3 says "Use const whenever possible", and it gives an example like:

 

const Rational operator*(const Rational& lhs,
                            const Rational& rhs);

to prevent clients from being able to commit atrocities like this:

Rational a, b, c;
...
(a * b) = c;   // invoke operator= on the result of a*b!

But isn't the non-reference return value of functions allready a rvalue? So why bother doing this?

GotW #90 Solution: Factories -- Herb Sutter

The solution to the latest GotW problem is now available:

GotW #90 Solution: Factories (updated for C++11/14)

by Herb Sutter

From the article:

Guideline: A factory that produces a reference type should return a unique_ptr by default, or a shared_ptr if ownership is to be shared with the factory.

Guideline: A factory that produces a non-reference type should return a value by default, and throw an exception if it fails to create the object. If not creating the object can be a normal result, return an optional<> value.

GCC 4.8.1 released, C++11 feature complete

The release of GCC 4.8.1 was announced today (31 May 2013) on the gcc mailing list. In addition to many bug fixes, GCC 4.8.1 adds support for C++11 ref-qualifiers, the final missing C++11 feature. This makes GCC the first C++11 [Ed.: language specification] feature complete compiler to be released.

Information on the full set of changes is available on the GCC 4.8 series page. 

Clang 3.3, also C++11 feature complete, is in release testing and the release is currently scheduled for June 5th. Within a week full C++11 support will be available from two major compilers and on numerous platforms supported by those compilers.

Forging ahead with support for the next C++ standard.

C++ auto and decltype Explained -- Thomas Becker

Here's a nice detailed treatment of auto and decltype by longtime author Thomas Becker.

C++ auto and decltype Explained

by Thomas Becker

From the article:

A while later, sometime in 2012, I noticed that there was another feature, or rather, a pair of features, in C++11 that I had not fully understood, namely, the auto and decltype keywords. With auto and decltype, unlike rvalue references, the problem is not that they are difficult to grasp. On the contrary, the problem is that the idea is deceptively easy, yet there are hidden subtleties that can trip you up.

Let's start with a good look at the auto keyword...