Prevent precondition errors with the C++ type system

In the previous part of the error handling series I’ve talked about assertions and wrote a debug assert library that provides flexible assertions.

Assertions are a useful tool to check preconditions of functions - but proper type design can prevent situations where assertions are needed. C++ has a great type system, let’s use it to our advantage.

At the recent CppCon Ben Deane gave a - as far as I’ve heard - great talk about type design. I sadly didn’t attend the conference and his video isn’t released yet but according to the slides there is some overlapping between his talk and what I’m going to say. But because I’ve planned this posts for weeks and even made the entire series just for it I decided to post it anyway. After all: some things cannot be said often enough.

Also I’m going to focus explicitly about type design for error handling, while his talk seems to be more generic.

» read more »
Author's profile picture Jonathan

How do I implement assertions?

In part 1 of the series I’ve talked about various error handling strategies and when to use which one. In particular, I said that function precondition should only be checked with debug assertions, i.e. only in debug mode.

The C library provides the macro assert() for checking a condition only if NDEBUG is not defined. But as with most things coming from C, it is a simple but sometimes not sufficient solution. The biggest problem I have with it is that it is global, you either have assertions everywhere or none. This is bad, because you might not want to have assertions enabled in a library, only in your own code. For that reason, many library programmers write an assertion macro themselves, over and over again.

Instead, let’s write same thing better ourselves, but something we can easily reuse.

» read more »
Author's profile picture Jonathan

Implementation Challenge: Concepts in C++14

There is the concept TS, a technical specification for including concepts into C++17. Concepts have always been a … concept in C++. They are used to document constraints on template parameters. For example:

template <typename RandomAccessIterator, typename Comperator>
void sort(RandomAccessIterator begin, RandomAccessIterator end, Comperator comp);

This function has the requirement that begin and end are both random access iterators and comp is a comparison function. Right now, the concepts are only documented and ignoring them leads to great error messages. The concept TS provides ways to embed them in the language directly and make, for example, overloading based on the concept easier.

But it doesn’t really bring anything new to the language. Everything it does can be accomplished with C++11’s expression SFINAE today, it only brings an (arguably) cleaner syntax and more complexity to the language.

In this post I’ll show you how to do implement concepts using only C++14 language features. I’ll try to make it as easy as possible by introducing some library utilities you can use very easily.

» read more »
Author's profile picture Jonathan

Choosing the right error handling strategy

To quote a previous post: “Sometimes things aren’t working.” If something isn’t working, you have to deal with it. But how?

There are two fundamental kinds of strategies: recoverable error handling (exceptions, error return codes, handler functions) and un-recoverable error handling (assert(), abort()). When do I use which one?

» read more »
Author's profile picture Jonathan

Move semantics and default constructors - Rule of Six?

A really long time ago - over four weeks! - I wrote about move safety.

I really need to force myself into blogging on a schedule. Let’s say I’ll publish something at least every two weeks.

The post spawned a lot of discussion about whether you should rely on moved-from state behavior or make any guarantees. See the first half of this CppChat episode for more.

BTW: Thanks for the nice words, Jon! Really appreciate it.

But I’m not going to continue that discussion. Both sides have convincing arguments and I don’t really want to advocate for one side here.

Instead I’m going to talk about something else related to the C++ move semantics, that couldn’t fit into the original post: The relationship between a default constructor and move semantics.

» read more »
Author's profile picture Jonathan