Do you feel that resources like the boost libraries will provide this functionality/accessibility for C++?

Some of the boost libraries - especially the networking library - are a good beginning. The C++0x standard threads look a lot like boost threads. If at all possible, a C++ programmer should begin with an existing library (and/or tool), rather than building directly on fundamental language features and/or system threads.

In your opinion, what lasting legacy has C++ brought to computer development?

C++ brought object-oriented programming into the main stream and it is doing the same for generic programming.

If you look at some of the most successful C++ code, especially as related to general resource management, you tend to find that destructors are central to the design and indispensible. I suspect that the destructor will come to be seen as the most important individual contribution - all else relies on combinations of language features and techniques in the support of a programming style or combinations of programming styles.

Another way of looking at C++'s legacy is that it made abstraction manageable and affordable in application areas where before people needed to program directly in machine terms, such as bits, bytes, words, and addresses.

In the future, I aim for a closer integration of the object-oriented and generic programming styles and a better articulation of the ideals of generality, elegance, and efficiency.

Where do you envisage C++'s future lying?

Much of where C++ has had its most significant strength since day #1: applications with a critical systems programming component, especially the provision of infrastructure. Today, essentially all infrastructures (including the implementation of all higher-level languages) are in C++ (or C) and I expect that to remain the case. Also, embedded systems programming is a major area of use and growth of C++; for example, the software for the next generation US fighter planes are in C++ (see the JSF++ coding rules on my home pages). C++ provides the most where you simultaneously need high performance and higher-level abstractions, especially under resource constraints. Curiously, this description fits both an iPod and a large-scale scientific application.

Has the evolution and popularity of the language surprised you in anyway?

Nobody, with the possible exception of Al Aho (of Dragon book fame), foresaw the scale of C++'s success. I guess that during the 1980s I was simply too busy even to be surprised: The use of C++ doubled every 7.5 months, I later calculated - and that was done without a dedicated marketing department, with hardly any people, and on a shoestring budget. I aimed for generality and efficiency and succeeded beyond anyone's expectations.

By the way, I occasionally encounter people who assume that because I mildly praise C++ and defend it against detractors, I must think it's perfect. That's obviously absurd. C++ has plenty of weaknesses - and I know them better than most - but the whole point of the design and implementation exercise was not to make no mistakes (that's impossible on such a large scale and under such Draconian design constraints). The aim was to produce a tool that - in competent hands - would be effective for serious real-world systems building. In that, it succeeded beyond my wildest dreams.

How do you respond to criticism of the language, such as that it has inherited the flaws of C and that it has a very large feature set which makes it 'bloated'?

C++ inherited the weaknesses and the strengths of C++, and I think that we have done a decent job at compensating for the weaknesses without compromising the strengths. C is not a simple language (its ISO standard is more than 500 pages) and most modern languages are bigger still. Obviously, C++ (like C) is "bloated" compared to toy languages, but not really that big compared to other modern languages. There are solid practical reasons why all the languages used for serious industrial work today are "bloated" - the tasks for which they are used are large and complex beyond the imaginations of ivory tower types.

Another reason for the unpleasantly large size of modern language is the need for stability. I wrote C++ code 20 years ago that still runs today and I'm confident that it will still compile and run 20 years from now. People who build large infrastructure projects need such stability. However, to remain modern and to meet new challenges, a language must grow (either in language features or in foundation libraries), but if you remove anything, you break code. Thus, languages that are built with serious concern for their users (such as C++ and C) tend to accrete features over the decades, tend to become bloated. The alternative is beautiful languages for which you have to rewrite your code every five years.

Finally, C++ deliberately and from day #1 supported more than one programming style and the interaction of those programming styles. If you think that there is one style of programming that is best for all applications and all people - say, object-oriented programming - then you have an opportunity for simplification. However, I firmly believe that the best solutions - the most readable, maintainable, efficient, etc., solutions - to large classes of problems require more than one of the popular programming styles - say, both object-oriented programming and generic programming - so the size of C++ cannot be minimized by supporting just one programming style. This use of combinations of styles of programming is a key part of my view of C++ and a major part of its strength.