Articles & Books

Passing Booleans to an Interface in an Expressive Way--Jonathan Boccara

Readability is important.

Passing Booleans to an Interface in an Expressive Way

by Jonathan Boccara

From the article:

In order to allow a function to behave in several different way, and to allow its caller to choose amongst these behaviours, we have several tools at our disposal. Plenty, actually.

There are various sorts of polymorphisms embedded in the language such as virtual functions and templates. And we’ve also seen that a caller can specify the desired behaviour explicitly at call site. We’ve seen how to accomplish this by using tag dispatching, and also how to choose between enums and tag dispatching depending on your need.

I now want to top it off with a really simple technique, that will cost you almost nothing, but one that will make your code much more expressive. And even if it’s not rocket science I’m sharing this with you today because I’ve seen many a piece of code that could have benefited from it...

Without form and void--Barry Revzin

Did you encounter the problem?

Without form and void

by Barry Revzin

From the article:

In C++, void is a pretty strange thing. We can cast expressions to void, throw-expressions have void type, void* can point to anything, and void functions can actually return back to the caller. But we can’t have objects of type void or even write a type like void&. A function declaration like void f(void) is actually a nullary function. It’s a bit weird — but it’s not something a lot of people lose sleep over.

Until it starts wreaking havoc on your generic code — because it’s like the vector<bool> of the type system...

[[trivial_abi]] 101--Arthur O’Dwyer

Interesting!

[[trivial_abi]] 101

by Arthur O’Dwyer

From the article:

Finally, a blog post on [[trivial_abi]]!

This is a brand-new feature in Clang trunk, new as of about February 2018. It is a vendor extension to the C++ language — it is not standard C++, it isn’t supported by GCC trunk, and there is no active WG21 proposal to add it to the standard C++ language, as far as I know...

When to Use Enums and When to Use Tag Dispatching in C++--Jonathan Boccara

What is your preference?

When to Use Enums and When to Use Tag Dispatching in C++

by Jonathan Boccara

From the article:

Enums and tag dispatching are two ways to introduce several behaviours in the same interface in C++. With them, we can pass arguments that determine a facet of how we want a function to behave.

Even if enums and tag dispatching have that in common, they achieve it in a quite different way. Realizing what these differences are will give you tools to decide which one to use in any given situation...

Your handy cut-out-and-keep guide to std::forward and std::move--Glennan Carnie

Do you know it?

Your handy cut-out-and-keep guide to std::forward and std::move

by Glennan Carnie

From the article:

I love a good ‘quadrant’ diagram.  It brings me immense joy if I can encapsulate some wisdom, guideline or rule-of-thumb in a simple four-quadrant picture.

This time it’s the when-and-where of std::move and std::forward.  In my experience, when programmers are first introduced to move semantics, their biggest struggle is to know when (or when not) to apply std::move or std::forward.  Usually, it’s a case of “keep apply std::move until it compiles”.  I’ve been there myself.

To that end I’ve put together a couple of a simple overview quadrant graphics to help out the neophyte ‘mover-forwarder’.  The aim is to capture some simple rules-of-thumb in an easy-to-digest format...

Exceptional exploration (2) -- Lucian Radu Teodorescu

Are you exceptionally curious?

Exceptional exploration (2)

by Lucian Radu Teodorescu

From the article:

To use or not to use exceptions? That is the question. Asked again.

In the previous post we explored the performance implications of various error handling mechanisms. Here we continue our exploration of error handling mechanisms but focusing on modifiability – i.e., the ability of the code to be easy to write and be modified in the future.

We argue that exceptions are both a good thing and a bad thing. We attempt to divide the scenarios into multiple categories, and we provide reasons pro and con for each category. The goal is to find the contexts in which it’s better to use exceptions. The answer may be surprising: there are more cases in which manual error handling is better than using exceptions. If only standard library would support non-exception policies…

Exceptional exploration (1) -- Lucian Radu Teodorescu

Are you exceptionally curios?

Exceptional exploration (1)

by Lucian Radu Teodorescu

From the article:

To use or not to use exceptions? That is the question.

And if you have hoped for a simple answer, this is not the right blog to read. On this blog, finding the truth is always a complex endeavor, it involves a complex mix of perspectives and a variety of interpretations. If you are into truthing, read on.

In this post we would only cover the performance aspects of it. A follow up post should discuss aspects like modifiability (how easy is to write error handling) and appropriateness of using exceptions.

ACCUConf 2018 Trip Report--Arne Mertz

Were you there?

ACCUConf 2018 Trip Report

by Arne Mertz

From the article:

Two weeks ago, I attended the ACCU Conference in Bristol again, and again it was a blast. ACCUConf is by far the most interesting and enjoyable conference I have attended so far...

Quick Q: How can unique_ptr have no overhead if it needs to store the deleter?

Quick A: The default deleter does not store anything.

Recently on SO:

How can unique_ptr have no overhead if it needs to store the deleter?

std::unique_ptr<T> is quite likely to be zero-overhead (with any sane standard-library implementation). std::unique_ptr<T, D>, for an arbitrary D, is not in general zero-overhead.

The reason is simple: Empty-Base Optimisation can be used to eliminate storage of the deleter in case it's an empty (and thus stateless) type (such as std::default_delete instantiations).