March 2012

I plan to give a brand-new talk for the first time at C&B, but I’m conflicted regarding what to say about it here because it’s recently been a bit of a startling realization to me about C++11, and I think it may be a bit startling for others too. I don’t want to be a tease, but I also want to save it as a surprise for C&B itself.

In the meantime, here’s a teaser…

In addition to the many new C++11 features that everyone’s listing, it has dawned on me over the winter that there’s actually another major change that isn’t being talked about anywhere, or even being listed as a change in C++11 at all as far as I know, because I and other key experts and committee members I’ve asked didn’t fully realize that we altered the basic meaning of not one but two fundamental keywords in C++. It’s a change that has profound consequences, that rewrites and/or invalidates several pieces of pre-C++11 design guidance, and that’s directly related to writing solid code in a concurrent and parallel world. This isn’t just an academic change, either — everyone is going to have to learn and apply the new C++11 guidance that we’ll cover in this session.

I plan to talk about it first at C&B, in a session tentatively titled as above — I’ll fill in the keywords later. You may already guess a few keyword candidates based on the description above, and here’s a final hint: You’ll hardly find two C++ keywords that are older, or whose meanings are more changed from C++98 to C++11. (No, they aren’t auto and register.)


As Herb and Andrei and I determine the topics we’ll address in our technical sessions at C&B 2012, we’ll post them here. We’ll also post topics we may discuss–prospective sessions. In both cases, we welcome your feedback. What follows is the first session announcement for C++ and Beyond 2012.

Universal References in C++11
T&& Doesn’t Always Mean Rvalue Reference

Perhaps the most significant new feature in C++11 is rvalue references; they’re the foundation on which move semantics and perfect forwarding are built. An rvalue reference is declared like a “normal” reference (now known as an lvalue reference), except you use two ampersands instead of one, i.e., “T&&” instead of “T&”. A reasonable expectation would be that if you see a type declaration involving “&&”, you’re looking at an rvalue reference, but that’s not the case:

  int&& var1 = 10;                  // here, “&&” means rvalue reference
  auto&& var2 = var1;               // here, “&&” does not mean
                                    // rvalue reference 
  template<typename T>
  void f(std::vector<T>&& param);   // here, “&&” means rvalue reference 
  template<typename T>
  void f(T&& param);                // here, “&&” might mean
                                    // rvalue reference

In this talk, I describe the two meanings of “&&” in type declarations, explain how to tell them apart, and introduce new terminology that makes it possible to unambiguously communicate which meaning of “&&” is intended. Distinguishing the different meanings is important, because if you think “rvalue reference” when you see && in a type declaration, you’ll misread a lot of C++11 code.

Our journey through DoubleAmpersandVille will include some interesting sights, including glimpses of the three different sets of type deductions rules in C++11, why “const T&&” does far more than just add const to “T&&”, how the token sequence “T&&” (where T is a template type parameter) can have completely different meanings in different function templates, and what decltype has in common with auto and templates. It’ll be a fun, illuminating ride, and by the time it’s over, you’ll be able to distinguish rvalue references from their syntactic twins with aplomb.


Now that registration for C++ and Beyond 2012 has begun, we’ll be making blog posts with increasing frequency to keep you apprised of developments related to the event. Among the most important posts will be those announcing topics for our technical sessions. Those posts will start later this week. (Because we typically develop all-new presentations for C++ and Beyond, we’re not in a position to announce the topics many months in advance. Instead, we let you know about them as we come up with them. In some cases, we’ll post about prospective sessions, and we’ll ask for feedback about how useful you think such sessions would be.)

Conceptually, we assume that people interested in C&B-related developments subscribe to the RSS feed for this blog. In reality, we know that blogs and RSS feeds are not everybody’s preferred mechanism for consuming information. As a result, our blog posts are automatically reflected to our twitter stream, our facebook page, and our mailing list. Practically speaking, we use the C&B blog as stdout for what we have to say, but we pipe that to other streams that may be more convenient for you. If you think we should pipe our posts elsewhere (other than to /dev/null, ahem), let us know.

Links to our RSS feeds, our twitter stream, our facebook presence, and our mailing list are in the sidebar on the right at the C++ and Beyond web site. They’re also embedded in the paragraph above.