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.

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?

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.

Two months ago I’ve released standardese version 0.1. I promised that the next version wouldn’t take so long as the first one - which took one month.

Well, I’m really not good as estimates.

But this release brings the last missing features to make standardese an actually usable documentation generator: index generation, referring to other parts of the documentation and more output formats, as well as other amazing features like an overhauled comment system. Also a lot of internal changes and bug fixes.

C++ programmers have this notion of exception safety. It is a very useful concept. With it one can easily describe the post-conditions of a function if it throws.

There is another situation where you need to easily describe some post-conditions: when talking about the state of an object after a move operation, i.e. after a move constructor or move assignment operator. I thus want to introduce vocabulary for those post-conditions of the right-hand argument similar to the exception safety of a function: The move safety, if you will.

The exception safety describes the post-conditions of a function if the function throws an exception. Similarly, the move safety describes the post-conditions of the object after a move operation. It thus gives information about what can be done safely with a moved-from object.