Welcome to my blog.

As I mentioned in my previous article many features introduced in the latest C++ standards allow functional patterns to thrive in your codebase. Two ideas from that programming paradigm that I really like are currying and partial application.

• Introduce and briefly explain the two aforementioned concepts.

Since the advent of C++11 writing more functional code has become easier. Functional programming patterns and ideas are powerful additions to the C++ developer's huge toolbox. (I recently attended a great introductory talk on them by Phil Nash at the first London C++ Meetup - you can find an older recording here on YouTube.)

In this blog post I'll briefly cover some techniques that can be used to pass functions to other functions and show their impact on the generated assembly at the end.

(If you are familiar with lambdas and higher-order functions you can skip the following paragraphs.)

Perfect forwarding and forwarding references allow developers to write generic template functions that retain the lvalueness/rvalueness of passed arguments, in order to avoid unnecessary copies or support reference semantics without having to implement multiple overloads. (This article by Eli Bendersky explains them in depth. I will assume you're familiar with these concepts for the rest of the article.)

In this article, I'll show how to correctly capture perfectly-forwarded objects into lambdas:

• We'll take a look at an example that shows how using std::forward in lambda captures can produce unexpected results.

When writing generic code, it is sometimes useful to check whether or not a particular SFINAE-friendly expression is valid (e.g. to branch at compile-time). Let's assume that we have the following class declarations...

struct Cat
{
void meow() const { cout << "meow\n"; }
};

struct Dog
{
void bark() const { cout << "bark\n"; }
};

...and that we would like to write a template function make_noise(x) that calls x.meow() and/or x.bark() if they are well-formed expressions:

template <typename T>
void make_noise(const T& x)
{
// Pseudocode:
/*
if(x.meow() is well-formed)
{
execute x.meow();
}
else if(x.bark() is well-formed)
{
execute x.bark();
}
else
{
compile-time error
}
*/
}

"An Empirical Study on the Impact of C++ Lambdas and Programmer Experience", a recent research paper presented at ICSE' 16, sparked a lot of controversy (e.g on reddit and Hacker News) after claiming that the use of C++11 lambda functions is harmful to beginners and unhelpful to professionals.

After carefully reading the paper, which is available on Andreas Stefik, Ph.D.'s website for free, I genuinely think that it is misinformative and that the drawn conclusions are inaccurate due to the flawed approach taken for the experiments and due to the small sample size.

In this article, I will support my claims by quoting the original paper and explaining why the authors' work/conclusions are subpar. All blockquotes in this post are citations of doi>10.1145/2884781.2884849.

In my previous article, "visiting variants using lambdas - part 1", I wrote about a simple technique (using boost::hana) that allows variant visitation using lambdas.

The technique consisted in passing several lambdas to boost::hana::overload in order to create a "local" visitor, without having to define a class/struct.

While discussing upcoming C++17 features with other attendees at CppCon 2016, I was surprised to hear complaints about the fact that std::variant visitation requires an external callable object.

Even though std::visit requires an overloaded callable object as its first argument, it is possible to build such an object locally in the call site: this can easily be achieved by implementing something similar to std::overload, proposed in P0051R2.

The aforementioned task however becomes trivial when using boost::hana.