Bjarne Stroustrup, inventor of the C++ programming language, is a computer scientist and the College of Engineering Chair Professor of Computer Science at Texas A&M; University. He has always been highly involved in the standardization of C++. Since 2004, Bjarne and the standards committee have been busy hammering out the details of a new standard, temporarily titled C++0x. Bjarne was gracious enough to take time out of his busy schedule to speak with DevX C++ Pro, Danny Kalev, about new C++0x features and the state of the C++ language.

The C++0x standard will be finalized during 2009. Can you outline its major features and its overall importance to the C++ community?

We hope to vote out a draft standard for public review in October 2008 so that we'll be able to hand in a final draft for international vote in 2009. Because of this heavy ISO process, it's touch and go whether C++0x will be C++09, but there is still hope and the major features are now known (barring disasters). We can classify the extensions like this

Concurrency:

• memory model supporting modern machine architectures
• Threading ABI
• atomic types
• mutexes and locks
• thread local storage
• asynchronous message exchange

Libraries:

• regex: regular expressions
• unordered_map, etc. (hash tables)
• smart pointers
• array: fixed-sized array
• improvements to containers based on new C++0x features
• tuples
• date and time (maybe)
• various library components to held library builders

Language:

• rvalue references (move semantics)
• static_assert: static assertions
• variadic templates
• strongly typed enumerations with scoped enumerators
• constexpr: generalized constant expressions
• control of alignment
• delegating and inheriting constructors
• auto: deducing a type from an initializer
• decltype: a way of using the type of an expression in a declaration
• control of defaults
• nullptr: a name for the null pointer
• a range-based for loop
• lambda functions
• raw string literals
• UTF8 literals
• concepts (a type system for template arguments)
• initializer lists and uniform initializations syntax and semantics
• in-class member initializers

Lists are, by themselves, not very interesting, but you can read up on a description of my general philosophy for language evolution and some of the individual decisions in my HOPL-iii paper "Evolving a language in and for the real world: C++ 1991-2006." You can also find more information than you could possibly want on the committee's web site.

Basically, the "concurrency" features will standardize the basic layers needed to do systems programming in a multi-core world. Obviously, facilities for doing that already exist in C++ implementations, but they are not standardized. I'd have liked to see library support for some high-level concurrency models, but the committee didn't have the time or consensus for that.

"I'd have liked to see library support for some high-level concurrency models, but the committee didn't have the time or consensus for that."

The library facilities provide a set of new library components and some improvements to the existing ones. I would have liked to see many more, but the committee is a volunteer effort and we just didn't have the resources for a massive extension of what was offered. Fortunately, there are many libraries available "out there," possibly already on your machine. For example, many of the C++0x libraries (e.g., regex and unordered_map) are now shipped by major vendors and boost.org offers many components (for instance, file system and networking) that we'll probably soon see in the standard. There is also much talk of a technical report on the libraries we most wanted but had to postpone.

The language extensions are a varied lot. Fortunately most are small and fit together with each other and with existing facilities to make a better integrated language. Consider a few examples:

// using C++0x features:
vector<string> v = {"Gorm", "Harald", "Sven",  "Harald", "Knud" };
for (auto p = v.begin(); p!=v.end(); ++p) cout << *p <<'\n'; 
for (auto x : v) cout << x <<'\n';

I suspect most is pretty obvious. You can provide an initializer list directly for a vector, you can deduce the type of an iterator from its initializer, and iterate through a sequence without explicitly mentioning the iterator. More examples:

enum class Season { winter, spring, summer, fall };
int summer;			// doesn’t clash with Season::summer
Season s = Season::spring;	// note qualification
summer = s;			// error: no Season to int conversion
Season += Season::fall;	// error: can’t add Seasons

for_each(v.begin(), v.end(), [](const string& s) { cout << s <<'\n'; });

You can have enumeration types (class enums) that behaves more like types than glorified integers and the “lambda” notation ([], etc.) is a simplified notation for defining a function object. Each of these simple examples can without heroic effort be written today. However, in C++98 that code would be twice the size and in every case open opportunities for making errors and/or for introducing overhead.

Note that all "primitive" features are meant to be used in combination and in combination with existing features to solve problems. For example, there is no "magic" for initializing vectors in particular or even any new "magic" for constructors. Instead, the initialization of vector was achieved simply by a rule that state that an initializer_list<T> can be initialized by a list of any numbers of Ts {t1, t2, t3} for any type T. Given that rule, we simply give vector<T> a constructor that accepts an initializer_list<T>. Incidentally, this mechanism can also be used to eliminate about 80 percent of the uses of the type-unsafe stdargs macros.