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.

I got a user submitted question to CppQuiz.org 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.