I’ll be giving a talk at ACCU about when to use which pointer types and why.

While working on that I made some guidelines for rvalue references in interfaces which didn’t quite fit the talk, so I’m writing about them here.

When should you use rvalue references as function parameters?

When as return types?

What are ref-qualified member functions and when and how should you use them?

Let’s tackle it one by one.

Like many open source developers I use GitHub to publish my work. It comes with a built-in issue tracking system, however, it isn’t that great.

The main issue - no pun intended - I have with it is that there is not an easy way to see all open issues and pull requests on all repositories you have. There is the issue workspace, but it only shows issues I’ve created, where I’m mentioned, or I’m assigned to. This isn’t helpful in my case, so I’ve looked for a different solution. There are also so-called “Projects”, but they are just for one repository - I need one for all.

I finally found a solution: It uses Trello and If This Then That.

A while back — but sadly not too many blog posts ago — I wrote about explicit constructors and how to handle assignment. In this blog post, I made the assumption that you most likely want to have explicit single argument constructors.

But when do we actually want implicit single argument constructors?

Let’s consider the broader question: How should I design a cast operation for my user-defined type? And how should I design a constructor?

But first, something different: what is the difference between a cast and a constructor?

C++ as a language is moving away from the classical, “Java style”, object-oriented programming. Long gone are the days of grand, virtual hierarchies. They’ve been replaced with standalone classes, free functions and type erasure.

And the benefits are clear: Instead of reference semantics, they allow value semantics which are simpler and more natural for C++. Instead of intrusive interface inheritance, they allow external duck-typing.

So in the spirit of this movement, let’s take a look at one OOP pattern and see if we can adopt it to this style: the visitor pattern.

This isn’t the blog post I wanted to publish today, this is the blog post I had to publish.

Simon blogged about using ADTs for error handling, leading to an interesting reddit discussion. Then Vittorio wanted to share his thoughts on the matter, leading to an even bigger reddit discussion. Now I’d like to chime in and offer a reasonable solution.

It is the age-old question: return codes vs exceptions. But this time, return codes have gotten an upgrade: std::expected and similar types.