An Interview with C++ Creator Bjarne Stroustrup

With the new C++0x standardization process about to have the final technical vote we sit down with C++ creator Bjarne Stroustrup to talk about C++0x, new features and future plans.

Danny Kalev: Where is the C++0x standardization process standing these days? How close are we to a new International Standard?

Bjarne Stroustrup: The final technical vote is scheduled for March 26, 2011. I see no reason for that to fail. After that, there are formal national ballots and ISO bureaucratic delays, but I’m pretty confident that the official standard will be available in 2011.

Danny Kalev: In terms of core features and library enhancements, which good tidings does the C++0x bring to the typical C++ programmer? Which aspects of C++0x make you particularly proud? Finally, what are your recommended techniques for learning the new features of C++0x, considering that C++0x textbooks are still a rarity?

Bjarne Stroustrup: The improvements to C++ come in the form of many small and incremental improvements, rather than a few “marquee” features. I guess some of the improvements won’t seem minor to many, but that’s even better and don’t detract from my key point: The C++0x improvements are pervasive; they help in many places in many kinds of code, rather than being isolated to a few new components. The way I think of it is that I’m getting a lot of new kinds of “bricks” to form my “building set” so that I can build many things that I couldn’t easily build before, and far more easily and elegantly. In fact, it is hard for me to think of any program that I can’t write a bit easier and more elegantly in C++0x than in C++98 – and typically have it perform better also.

Let me first mention a couple of near-trivial changes that make life just a bit easier for the C++ Programmer. Consider:

		  void f(vector<pair<string,int>>& vp)
		  {
		      struct is_key {
		          string s;
		          bool operator()(const pair<string,int>&p)
		              { return p.first == s; }
		      };
		      auto p = find_if(vp.begin(), vp.end(), is_key{"simple"});
		      // …
		  		}
		

This doesn’t look particularly new or exciting, but I count four little “things” that are not C++98:

  1. There isn’t a space between > and > in vector<pair<string,int>>. I rate this the smallest improvement in C++0x; it saves the programmer from having to add that “spurious” space (learn more about this issue here).
  2. I declared p without explicitly mentioning the type of p. Instead, I used auto, which means “use the type of the initializer.” So p is a vector<pair<string,int>>::iterator. That saves a fair bit of typing and removes the possibility of a few kinds of bugs. This is the oldest C++0x feature; I implemented it in 1983, but was forced to take it out for C compatibility reasons.
  3. The local struct is_key is used as a template argument type. Maybe you didn’t even notice, but that was not allowed in C++98.
  4. Finally, I made a key using the initializer {“simple“}. In C++98, that could only be done for a variable and not as a function argument. C++0x offers uniform and universal initialization using the {…} notation.

We might simplify this example further by using a lambda expression:

		  void f(vector<pair<string,int>>& vp)
		  {
		  auto p = find_if(vp.begin(), vp.end(),
		      []()(const pair<string,int>&p) { return p.first=="simple"; });
		  // …
		  		}
		

The lambda notation is an abbreviation for a function object definition and use. Here, we simply say that the predicate required by find_if() takes pair argument and compares its first element to “simple”.

OK, such minor improvements are all very good, but what about more major issues?

  • Direct and type safe support for the traditional threads-and-locks style of system-level concurrency. Together with a detailed memory model and facilities for lock-free programming, this provides support for portable and efficient concurrency.
  • A higher-level concurrency model based on asynchronously launched “tasks” communicating through message buffers called futures.
  • A regular expression standard library component
  • Hashed containers
  • Move semantics and the use of move semantics in the standard library. In particularly, we can now return large objects from functions by value. For example:

      vector<int> make_vec(int n)
      {
          vector<int> res;
          for (int i=0; i<n; ++i) res[i] = rand_int(0,100000);
          return res;
      }
    

    The standard library’s vector has a “move constructor” that simply transfers the representation of the vector representation rather than copying all the elements. This implies that the return is accomplished by something like six assignments (rather than, say, a million), so that we don’t have to fiddle with pointers, references, free store allocation and deallocation, etc. This provides a whole new paradigm for passing large objects. In particular, it makes it trivial to implement and use value producing operations that need to be efficient, such as a matrix add:

      Matrix operator*(const Matrix&, const Matrix&);
    

I could go on for a while, but long lists get tedious and anyway, this leads us to the second and more interesting part of the question: How will people learn to use all of this well? I’m working on a 4th edition of The C++ Programming Language, but that’s a huge amount of work. It will take at least another year. I’m sure other authors are writing or thinking about starting to write, but it will be a while before we have quality books and teaching materials for experts and novices. We are lucky to have a good early source of information related to concurrency: Anthony Williams: C++ Concurrency in Action – Practical Multithreading. Another early source is my C++0x FAQ. That FAQ presents short examples of uses of most C++0x language features and standard-library facilities and references to currently available material. However, we need more than FAQs and online documentation. We need coherent explanations of how to use the facilities in support of good programming. For that, we need textbooks.

When I wrote Programming: Principles and Practice using C++, I was simultaneously working on C++0x and it was painful not to be able to use C++0x features. I confidently predict that C++0x will be a boon to education/learning. The support for good programming techniques and styles is so much better now. For example, we now have a uniform and universal mechanism for initialization. We can use the {…} notation for every initialization and wherever we initialize an X with {v} we get the same resulting value. That’s a major improvement over C++98’s non-uniform set of alternatives using the =v, ={v}, and (v) notations:

  vector<double> v = { 1,2,3,4};	// a user-defined type
  double a[] = { 1,2,3,4};		// an aggregate
  int f(const vector<double>&);
  int x = f({1,2,3,4});
  auto p = new vector<double>{1,2,3,4};
  struct S { double a, b; };
  S s1{1,2};			// has no constructor
  complex<double> z { 1,2,};	// has constructor

Before we get to benefit from the simplifications offered by C++0x, we may go through a period where too many people try to show off their cleverness by enumerating language rules and digging into the most obscure corners. That can do harm.

We cannot expect people to gain a good understanding of C++0x programming just from reading. People have to actually use the new features. Given that, it is good that implementations of many of the C++0x features are currently shipping (e.g. in GCC and Microsoft C++) as are essentially all of the new standard-library components. C++0x is not Science Fiction!

Danny Kalev: The C++0x standard is three years behind schedule. The Perl 6 and Java SE 7 releases also exhibited significant delays. It seems that standardization projects these days take much longer than before. Is it something inherent to the programming languages of the 21st century? Is it the standardization process itself? Or perhaps this has always been the case?

Bjarne Stroustrup: The languages themselves are larger than programming languages used to be; the libraries that come with them even more so. Also, the code bases that must not be broken are huge. On top of that, the cost/time of dealing with complexity does not go up linearly with size. I suspect that the difficulty goes up at least quadratically because of the need to consider all possible interactions among language and standard library features.

The nature of the standards processes have changed to take that into account. Furthermore, the use of online communications has increased the number and variety of people who can take part. Two decades ago, the number of people who could take part was basically limited to those with major corporate or university funding and with time to spend weeks at meetings and months at home preparing. My guess is that between 100 and 200 people had an active role in shaping C++98. Maybe four times as many people took similar active roles in the C++0x effort. The extra manpower is most welcome and the work of so many people is essential for ironing out problems. However, it is always easier to prevent a change than to make one, the larger group is less homogeneous in aims and backgrounds, and the trust necessary for progress is harder to establish in a large group and over the web than in a smaller group repeatedly meeting face to face. Also, fewer people understand or care for the whole language and the whole user community – it is always easier to focus on a small subset and there is a danger of dismissing the concerns of communities you don’t know as irrelevant or even “simply wrong.”

The sum of these two effects is an increasingly conservative bias. Maybe I should be amazed that we achieved as much as we did. Getting an idea (a “vision,” if you must) through the technical and philosophical obstacles in the committee can be infuriatingly slow and difficult. In particular, FUD is a powerful weapon because it is essentially impossible to prove that a new feature will provide significant benefits when deployed at scale, whereas it is usually easy to imagine potentially serious problems.

Related Articles



More by Author

Must Read