Help save! We’re porting to C++17.

[start helping now] is an open source C++ quiz site ran by me, with contributions from the C++ community. If you’re unfamiliar with it, you can read more in its “About” section

All the CppQuiz questions are currently targetting C++11. We need to update them for C++17. Most questions will still have the same answers, we just need to update the explanations and references to the standard. A few questions will also have different answers.

Doing this all by myself is going to take months, so I would very much appreciate some help from the community. Everyone who helps will be credited in a blog post when the porting is done.

To make porting as simple as possible, I’ve created a repository containing all the questions. There is a directory for each question, named after the question number. That directory contains the source code of the question in a .cpp file, the hint and explanation in .md files, as well as a explaining everything you need to do to port the question. There’s also an issue for each question, making it easier to track progress. The issue has the same information as the file.

As soon as we’ve updated all the questions in this repository, I’ll import them back into CppQuiz, and from then on CppQuiz will always ask about C++17.

How to help porting questions

There are two ways to contribute, listed below. I prefer the first alternative, but if that prevents you from contributing, the second is also ok.

Contributing using a fork and pull requests

  1. Fork the repo by clicking the “Fork” button at the top right.
  2. Pick the issue for a question you want to port. Add a comment that you’ll be handling that issue.
  3. Follow the instructions in the issue to port the question.
  4. Make a pull request. Porting several questions in one PR is fine.

Contributing without a fork

If you think forking and PRs is too cumbersome, or you are not able to do this for other reasons, I’d still appreciate your help:

  1. Pick the issue for a question you want to port. Add a comment that you’ll be handling that issue.
  2. Follow the instructions in the issue to port the question.
  3. Paste the updated files as comments to the issue.

Other ways to help

  • Look for questions labeled “help wanted”. It means the person responsible needs a second pair of eyes.
  • Look at pull requests, review them and comment “LGTM” if they should be merged.
  • Other ideas for help are also welcome, please get in touch (see “Questions” below).


If you have any questions, either file an issue in the repo, contact @knatten on Twitter, or email me at

[start helping now]

New job: Zivid Labs!

I know it’s not Friday, but I couldn’t wait to share this: Yesterday I signed the contract for my new job as senior developer at Zivid Labs!

While looking for a new position this time, I talked to a lot of cool companies. Zivid stuck out as the most interesting, and I’m very happy to have been accepted into their team!

Zivid have made the world’s most accurate real-time 3D color camera. In other words, the world’s coolest eyes for robots 😎. The main API is in modern, clean C++, with bindings to other languages as well. My main role will be working on the C++ parts of the API, as well as other C++ systems and frameworks. This is actually my first C++ job for over five years, so you can expect me to increase activity both on this blog and on C++ conferences, both of which I really look forward to!

Why did I choose Zivid?

  • They make a really cool product!
  • They have very high ambitions for the developer experience of their users (this is important to me, as it sets a very high bar for code quality, API quality, docs quality etc.)
  • Even though they’re a “hardware company”, they treat software as a first class citizen, and an equally important success factor as the hardware itself
  • I met some great people during my interviews there, all of which I really wanted to work with
  • They have very experienced owners, like SINTEF and Geir Førre (Chipcon, Energy Micro)
  • They recently started shipping their first product, and the first customers seem to be very impressed

Now it’s time to finish paternity leave, have a few weeks of much needed vacation, then I’ll join the team on 1 October. I’m really looking forward to joining an awesome team making an awesome product!

Trying out C++17 on macOS

Update: This article is more than a year old. Recent versions of macOS ship with much better C++17 support out of the box, so you should check whether your default Clang already supports your use case before bothering with this approach.

C++17 brings a lot of cool new features. Viva64 have a nice overview. Sadly, they can’t all be used out of the box on macOS, as the default toolchain isn’t very modern.

The problem

Apple installs their own version of llvm along with Xcode. This custom llvm also uses custom version numbers, so it isn’t always easy to know which version of mainline llvm it is based on. For instance on my macOS High Sierra, I get:

$ clang --version
Apple LLVM version 9.0.0 (clang-900.0.39.2)

This version number has nothing to with the official llvm version, which is currently at 6.0.0. All I know is that it is behind.

The solution(s)

If you want to try out some new features today, you have a few options:

  • Use std::experimental to play with certain features
  • Install a more modern llvm

Using std::experimental

Sometimes, the C++ standards committee publishes experimental C++ language and library extensions for future standardization. These go in the std::experimental namespace. If you just want to play with some new features, your toolchain might already include what you’re looking for here. However, be aware that these features as they exist in the experimental namespace are not guaranteed to be identical to how they end/ended up in the actual C++ standard! So this should just be used for toying around, not  for production code.

As an example, I wanted to try out the new optional feature. This was included in a technical specification, and has been available as std::experimental::optional for a while. Note however that its interface changed before being merged to the official standard as std::optional. The former for instance lacks the has_value member function.

Installing a more modern llvm

This is the proper solution. It’s not too hard either! First, you probably don’t want to risk breaking your current Xcode setup by installing a mainline llvm interfering with the Apple llvm used by Xcode. Luckily, homebrew avoids this problem by default, by installing llvm in another location than the Apple llvm, and not adding the new one to path.

Embedded Artistry has a good guide for this. In short, all you need to do is

$ brew install --with-toolchain llvm

This will take quite some time, and you’ll end up with mainline llvm (currently version 6.0.0) in a path you can find by running:

$ brew --prefix llvm

On my machine, I get:


I’m not going to copy paste their entire guide, so I suggest you read through it for the details of how to configure your project to use the newly installed mainline llvm instead of the apple llvm you have in path.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

lvalues, rvalues, glvalues, prvalues, xvalues, help!

Did you use to have some sort of intuition for what “lvalue” and “rvalue” meant? Are you confused about glvalues, xvalues and prvalues, and worry that lvalues and rvalues might also have changed? This post aims to give you a basic intuition for all five of them.

First, a warning: This post does not aim to give a complete definition of the five value categories. Instead, I only hope to give a basic intuition, which I hope will help to have in the back of your mind next time you need to look up the actual details of one of them. Feel free to flame me in the comment section, but I don’t promise I’ll bite! :)

Back before C++11, there were two value categories, lvalue and rvalue. The basic intuition was that lvalues were things with identities, such as variables, and rvalues were temporaries:


However, along came rvalue references and move semantics. On the surface, the old lvalue / rvalue distinction seems sufficient: Never move from lvalues (people might still be using them), feel free to move from rvalues (they’re just temporary anyway):


Why did I put “Can’t move” and “lvalue” in red in that diagram? It turns out that you might want to move from certain lvalues! For instance, if you have an lvalue you won’t be using anymore, you can std::move() it to cast it to an rvalue reference. A function can also return an rvalue reference to an object with identity.

So as it turns out, whether something has identity, and whether something can be moved from, are orthogonal properties! We’ll solve the problem of moving from lvalues soon, but first, let’s just change our diagram to reflect our new orthogonal view of the world:


Clearly, there’s a name missing in the lower left corner here. (We can ignore the top right corner, temporaries which can’t be moved from is not a useful concept.)

C++11 introduces a new value category “xvalue”, for lvalues which can be moved from. It might help to think of “xvalue” as “eXpiring lvalue”, since they’re probably about to end their lifetime and be moved from (for instance a function returning an rvalue reference).

In addition, what was formerly called “rvalue” was renamed to “prvalue”, meaning “pure rvalue”. These are the three basic value categories:


But we’re not quite there yet, what’s a “glvalue”, and what does “rvalue” mean these days? It turns out that we’ve already explained these concepts! We just haven’t given them proper names yet.


A glvalue, or “generalized lvalue”, covers exactly the “has identity” property, ignoring movability. An rvalue covers exactly the “can move” property, ignoring identity. And that’s it! You now know all the five value categories.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

Non-virtual destructors

I got a user submitted question to the other day where the contributor had gotten the answer wrong, and I didn’t notice at first. The question was about non-virtual destructors:

#include <iostream>

struct B {
  B() {
    std::cout << 'b';
  ~B() {
    std::cout << 'B';

struct D : B {
  D() {
    std::cout << 'd';
  ~D() {
    std::cout << 'D';

int main() {
  B* p = new D;
  delete p;

As usual on CppQuiz, the objective is to figure out the output of the program, according to the C++ standard. Before continuing, please try to find the answer yourself!

What does the standard say?

Did you reply bdB? So did the person who contributed the question, and I initially went “yep, that seems logical”. It does indeed seem logical that these functions are called, but what exactly happens when we fail to destroy the derived part of an object? Let’s have a look at §5.3.5/3 in the C++11 standard:

if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static type shall have a virtual destructor or the behavior is undefined.

The static type here is B, which is indeed a base class of the dynamic type D. The static type B does however not have a virtual destructor, so the behavior is undefined. (I have yet to see a compiler who doesn’t print bdB though.)

So why is this undefined behavior? It would be hard for the standard to specify exactly what happens when an object is not properly destroyed.

In practice, most compilers will probably go with the normal rules for virtual functions, print bdB, and simply not destroy the D part of the object. But since the behavior is undefined, there’s no guarantee for this.

One could argue that even if the result of not destroying D properly is undefined, the standard could still mandate which destructor(s) actually get called. However, when undefined behavior occurs in a program, the entire execution is undefined, so there really would be no point.

If you’re curious about undefined behavior, I’ve written about it before. That article also has links to some really interesting, more in-depth articles about the subject.

As usual, the code for this blog post is available on GitHub.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

How to contribute questions for

You might be familiar with my C++ quiz site, But did you know you can contribute your own questions to the site? First, try solving a few questions to get the gist of it, then visit to create your own.

I try to live by the “quality over quantity” motto for the questions on the site, so you’ll find the following guidelines on the submission form:

  • Your question should be short, and demonstrate one thing only
  • Your question should compile (unless not compiling is the point)
  • Your question should be about standard C++, not compiler specific or about 3rd party libraries
  • Your question should not be a trick question, and be free from distractions
  • Your explanation should be clear and to the point
  • Your explanation should use correct terminology, and refer to the standard where possible
  • Prefer well defined programs over programs with compilation errors, undefined or unspecified behaviour

But what does all of that mean?

Your question should be short, and demonstrate one thing only

The shorter the code in the question, the better. The point of a question is to teach one single aspect of C++, not to be an exercise in reading and understanding an unfamiliar code base.

Your question should compile (unless not compiling is the point)

It should be possible to copy your code verbatim and have it compile as C++11, without errors, requirements for additional includes etc. (Of course, some questions are not intended to compile, then this rule does not apply.)

Your question should be about standard C++, not compiler specific or about 3rd party libraries

This should be fairly self explanatory, don’t make questions about posix, boost, windows.h etc.

Your question should not be a trick question, and be free from distractions

I’ve refused several questions due to this. Your question is supposed to be non-trivial, but the difficulty should be to understand a concept of C++, not to read the question correctly, or find the clue in the midst of distractions. Don’t make questions where the key is noticing that the variables v1 and vl are not the same. Don’t make questions full of complicated C++ that doesn’t matter, but is just there to hide the simple core of the question.

Your explanation should be clear and the point

Don’t go on lengthy asides in the explanation. As your question is already short and demonstrates one thing only, explaining that single concept should not take too many words.

Your explanation should use correct terminology, and refer to the standard where possible

The chances of having your question published quickly increases if you use correct C++ terminology to describe the concepts in your question. It helps me a lot if you’re also able to provide references to the standard, but don’t let this stop you from contributing.

Prefer well defined programs over programs with compilation errors, undefined or unspecified behaviour

There’s a lot of fun and interesting things to learn from questions that don’t compile, or contain undefined or unspecified behaviour. It’s however not so fun when most of the questions on the site can be answered simply by enumerating those three alternatives as an answer.

That’s it! I hope I didn’t scare you away from contributing. Please have a go, and don’t be afraid to ask if you have any questions about your question! :)

Another Reason to Avoid #includes in Headers

I have already argued that you shouldn’t put all your includes in your .h files. Here is one more reason, compilation time.

Have a look at this example, where the arrows mean “includes”

file5.h apparently need access to something which is defined in file4.h, which again needs access to three other headers. Because of this, all other files that include file5.h also includes file[1-4].h.

In c++, #include "file.h" really means “copy the entire contents of file.h here before compiling”. So in this example, file[1-3] is copied into file4.h, which is then copied into file5.h, which again is copied into the three cpp files. Every file takes a bit of time to compile, and now each cpp file doesn’t only need to compile its own content, but also all of the (directly and indirectly) included headers. What happens if we add some compilation times to our diagram? The compilation time of the file itself is on the left, the compilation time including the included headers are on the right.

As we can see, this has a dramatic effect on compilation time. file6.cpp and file7.cpp just needed something from file5.h, but got an entire tree of headers which added 1.2 seconds to their compilation times. This might not sound much, but those numbers add up when the number of files is large. Also, if you’re trying to do TDD, every second counts. And in some cases, compilation times of individual headers can be a lot worse than in this example.

What if file5 didn’t really need to have #include "file4.h" in the header, but could move it to the source file instead? Then we would have this diagram:

The compilation time of file[6-7].cpp is significantly reduced.

Now let’s look at what happens if a header file is modified. Let’s say you need to make a minor update in file1.h. When that file is changed, all the files that include it need to be recompiled as well:

But if we were able to #include "file4.h" in file5.cpp instead of file5.h, only one cpp file would need to recompile:

Recompilation time: 1.7 seconds vs. 4.5 seconds. And in a large project, this would be a lot worse. So please try to move your #includes down into the cpp files whenever you can!

The Graphviz code and makefile for this blog post is available on GitHub.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

New Software Community, and Google Test Demo

Together with Håkon K. Olafsen, I founded Kjeller Software Community earlier this summer. Our first meetup is due this Wednesday (September 26). I will do a demo of Google C++ Testing Framework, aka. GoogleTest, and afterwards we will have a few beers and chat about programming and all things geeky. Hopefully we will also get some good suggestions for future events and meetups. The meetup will happen at Klimt pub in Lillestrøm, at 6:00 pm.

This meetup is done in cooperation with Oslo C++ Users Group, of which I am also a member. If you are into C++, and live in the greater Oslo area, that group is also highly recommended.

Notes from the talk, and a blog post about Google Test will be up later this week.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter. You can also follow Kjeller Software Community on Twitter.

Private Inheritance

In which I introduce private inheritance, but discourage its use.

When inheriting in C++, you normally see

class Derived : public Base {};

It’s almost as if public is synonymous to inherits from. But did you know there is also private inheritance, and why you (probably) don’t see it a lot?

When inheriting publicly from a base class, all base members will be accessible from the derived class, with the same accessibility as in the base class. Given these classes:

class Base
    void pub() {}
    void priv() {}

class DerivedPublic : public Base

class DerivedPrivate : private Base

Public inheritance results in this:

    DerivedPublic derivedPublic;;
    //derivedPublic.priv(); //error: ‘void Base::priv()’ is private

Whereas private inheritance results in this:

    DerivedPrivate derivedPrivate;
    //; //error: ‘void Base::pub()’ is inaccessible
    //derivedPrivate.priv(); //error: ‘void Base::priv()’ is private

So why would you want to inherit privately? To allow Derived to access the public members of Base, without exposing them to the users of Derived.

Inside the class, the members are accessible:

class DerivedPrivate2: private Base
    void foo() { pub(); }

But outside, they are not:

    DerivedPrivate2 derivedPrivate2;;
    //; //error: ‘void Base::pub()’ is inaccessible

But wait a minute, doesn’t this look a whole lot like the good old inheritance (is-a) vs. composition (has-a)? It does indeed! Private inheritance is really a has-a. And in most circumstances composition and private inheritance are interchangeable. However, since inheritance results in stronger coupling, the general recommendation is to choose composition instead. Here is how DerivedPrivate2 would look using composition:

class NotDerived
    void foo() {; }
    Base b;

Now you may be thinking: “But I read somewhere that you need to use private inheritance if you want to override a virtual Base method?” You probably did, and I’ll get back to that in the next post.

As usual, the code for this blog post is available on GitHub.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

Basic gloox Tutorial

There didn’t seem to be a basic gloox tutorial available, and the example on their home page is out of date, so I decided to write one. This tutorial is based on their example, but extended and updated to work with gloox version 1.0.

Since you are reading this, you probably already know, but gloox is a popular library for the Extensible Messaging and Presence Protocol (XMPP), formerly known as Jabber. In this basic tutorial I will demonstrate how to create an XMPP bot that connects to a server (using TLS), listens for messages, and answers them in an annoying way. If you just want the code, get bot.cpp from GitHub, compilation instructions are at the top of the file.

The first thing we need to do is set up a MessageHandler. This will connect to the server, and handle incoming messages.

class Bot : public MessageHandler {
    Bot() {
        JID jid("bot@localhost");
        client = new Client( jid, "botpwd" );
        connListener = new ConnListener();
        client->registerMessageHandler( this );

4: The ID of our user. In my example I use a local XMPP server, with a previously created user “bot”. (See the appendix for instructions on how to install an XMPP server.)
5: Here we create the client, with our ID and password.
6: We need a ConnectionListener to handle connections, I will get back to that later.
7: The Client needs a MessageHandler to handle incoming messages. Since the Bot itself inherits from MessageHandler, we just pass this.
8: The ConnectionListener must also be registered with the Client.
9: Finally we connect to the XMPP server. There are two ways to connect, blocking and non-blocking. In our example, we use blocking connections. If you go for non-blocking, you need to call Client::recv() at regular intervals to receive data.

To handle messages, Bot needs to implement a method handleMessage:

    virtual void handleMessage( const Message& stanza, MessageSession* session = 0 ) {
        cout << "Received message: " << stanza << endl;
        Message msg(stanza.subtype(), stanza.from(), "Tell me more about " + stanza.body() );
        client->send( msg );

2: Print the received message (using a custom operator<<).
3: Create a new message to whoever sent us a message, asking them to tell us more about this fascinating subject.
4: Send the message, using the Client we created in the Bot constructor.

We also need a ConnectionListener to handle connections. As a minimum it needs to override three pure virtual methods:

class ConnListener : public ConnectionListener {
    virtual void onConnect() {
        cout << "ConnListener::onConnect()" << endl;
    virtual void onDisconnect(ConnectionError e) {
        cout << "ConnListener::onDisconnect() " << e << endl;
    virtual bool onTLSConnect(const CertInfo& info) {
        cout << "ConnListener::onTLSConnect()" << endl;
        return true;

Here I just cout the names of the methods when they are called, to see that everything works. If there is an error, onDisconnect() displays the error code. The error codes can be found in gloox.h.
The main method to pay attention to is onTLSConnect(). This should check the TLS cert credentials, and return true if they are accepted. In this tutorial we accept whatever we get.

Then you can run main like this:

int main() {
    Bot b;

You can now chat with the bot using any XMPP client:
A Pidgin client talking to the bot
(See the appendix for instructions on installing and setting up an XMPP client.)

That’s it! Get the full code from GitHub.

To compile, you need to install gloox and pthreads. On Ubuntu, gloox is installed doing sudo apt-get install libgloox-dev, pthreads should come with your compiler. To compile using g++, do g++ -o bot bot.cpp -lgloox -lpthread. Other Linuxes should be similar. On Windows, download and install from, and read the included documentation.

If you enjoyed this post, you can subscribe to my blog, or follow me on Twitter.

Appendix A: How to install a local XMPP server
To test this, I installed ejabbered. If you are using Ubuntu, there is a simple, good tutorial available. As soon as ejabberd is installed, visit http://<servername&gt;:5280/admin/server/localhost/users/ and add the user “bot”, with password “botpwd”. Also add another user to play the other part of the conversation (I used “anders”).

Appendix B: How to install and test with an XMPP client
There are many XMPP clients available, I used Pidgin (sudo apt-get install pidgin on Ubuntu). After installing, open the main window (“Buddy List”) and select Accounts -> Manage Accounts -> Add. Select protocol “XMPP”, the other username you created on your XMPP server (not “bot”) and a domain (“localhost” if you are running on localhost). On the Advanced page, select port “5222”, server “localhost” (or whatever host you are running on). Click “Add”, and tick the “Enabled”-box in the list of accounts. Hit “Close”. Now go to the Buddy List again, select “Buddies”, “Add Buddy”. In “Buddy’s username”, enter “bot@localhost” (or whatever host you are running on).

If you have started your bot (./bot on the command line), you can now double-click on the bot in you Buddy List as you would normally do to chat with someone in any IM program, and type your message. If everything went according to plan, the bot will be very interested, and want to know more!