With the passage of C++14, many of our C++ curriculum plans are being left in the dust. C++14 is not just a theoretical language that’s going to “eventually come”: it’s here, right now, and it’s here to stay. There is already a completely conforming compiler (clang) and standard library (libc++) that is shipping on what is arguably the most popular computing platform among our students: Apple’s OSX.

Many companies (and research projects) have already begun to embrace C++11 (current examples: Apple, Facebook, Google, LLVM)—the reality of the situation is that our students are going to be encountering C++11/14 in the “real world” immediately after graduating.

Most courses that teach C++ right now are using C++03. This is a language that is nearly 11 years old! And that’s if we’re generous and really count C++03 (a very minor, bugfix release for the language) as a new language. Scott Meyers (rather famous in the C++ community) rarely makes a distinction between the two. If we too do not distinguish C++03 from C++98, then what’s really being taught is a language which is in its teens!

Now there’s nothing explicitly wrong with teaching an old language. There’s a lot of merit to teaching the Design Patterns course using Smalltalk, for example. Courses about programming languages and compilers can get very far by teaching in some dialect of Lisp. Good ideas in these languages don’t suddenly become stale: there’s a lot they can still teach us.

But what we’re talking about here isn’t just that C++98 is an old language. It’s a language that has been deprecated by the very existence of C++11. Sure, the techniques you learn for C++98 are not just going to stop working when you switch to C++11. There’s (almost) nothing about the language that isn’t backwards compatible.

But the way you express your ideas is different. And this is an important point. If you were to write code using C++98 idioms in a C++11/14 codebase, your code won’t have a chance of passing code review. Ideas are expressed not just differently, but in safer ways than before:

• Common C++ memory safety pitfalls can be completely eliminated via the combination of resource acquisition is initialization (an old concept) and move semantics (a new concept). (It’s worth noting that this idea of “move semantics” is also present in Mozilla’s Rust language, which is being designed from the ground-up to be a safe, systems-level language.)

• Code that was inefficient in C++98 that required horrible, nasty, error-prone workarounds is now instantly efficient in the presence of move semantics (and I don’t even need to rely on return value optimization).

We are obligated as educators to begin exposing our students to these better, more modern idioms for expressing their ideas through programs in C++.

And let me be clear: in doing so we do not lose anything compared to the old style of teaching.

Because I don’t really expect you to believe me, the next few posts in this series will attempt to demonstrate what I feel are the few (really, two) most important features in C++11/14 for teaching in the undergraduate curriculum. The discussion will be focused primarily on the current curriculum at UIUC (the basis for my observations), and thus will have a strong focus on teaching the following few learning objectives:

• Manual memory management (heap memory)
• Implementing classes that use resources (e.g., memory) in C++

Think I’m on to something? Or just insane? Shout it out in the comments!