[Email interview of Scott Meyers by Bernhard Merkle for iX Magazine.
Published in iX Magazine (in German) in September 2006.  The interview
itself took place in May 2006.]


>- Last year C++ had its 20th anniverary as language. 
>  What do you think, is C++ to be getting a bit long in the tooth ;-) ?

In some sense, it's an old-fashioned language, one that focuses more on
making efficient use of machine resources and giving programmers control
than on improving programmer productivity.  This is in contrast to newer
languages like Java, C#, and Ruby/Rails.  The managed environments and
extensive standard library functionality those languages provide are quite
attractive for lots of applications.  At the same time, they're weaker than
C++ for things like interfacing to hardware, conforming to legacy APIs or
data layouts, minimizing memory footprint, and maximizing performance.  My
feeling is that there will always be a need for a language that has
strengths in these areas, so perhaps a better way to look at C++ is that it
adheres to "classic" ideals of programming language beauty rather than
trying to fit in to the mold of current language fashion.

>- What do you think about other languages like Java or C# which gain more
>  and more importance ?  Do you think C++ will take a role in a limited
>  market beaucse of Java/C# ?

I've said for years that I think C++'s natural niche is the development of
demanding systems applications, and I think it will retain that role for
many years.  The role is limited, though of course the role for
"productivity languages" is limited, too.  I think C++ will become less
important in some areas (e.g., mainstream desktop application development
where there are no particularly demanding technical constraints) and more
important in others (e.g., embedded systems development, where C++ is
increasingly becoming the language of choice to replace C).

>- Especially in performace critical areas/applications, C++ seems to
>  replace C and Java/C# still are not ready to meet the requirements.  Will
>  the embedded marked be the new main market for C++ ?

I don't know if it will be the main market, but it will certainly be a very
important one.  However, C++ will also remain very strong in
performance-sensitive areas, e.g., video games, image processing, financial
applications (e.g., real-time analysis of investment markets), and
simulations of many types.  And C++ will continue to own the market for
template metaprogramming.  That's currently a tiny market, and I don't
think it will ever become large, but I do think it is likely to become
increasingly important.

>- What do you think about the new upcoming C++0x Std ?

From what I can tell, it will likely offer at least a few quite attractive
new language features, including static assertions, auto, and lambda
functions.  It will also probably offer concepts, which I don't personally
find terribly attractive, but other people seem excited about them.  And
the enhancements to the standard library foreseen by TR1 will be very nice.
My favorites there are shared_ptr, hash tables, and regular expressions,
but the other new library functionality will be a big help, too, especially
for people making heavy use of the STL or involved in template
metaprogramming.

>- Do you see C++ getting simpler with C++0x ?

Not in any meaningful way.  C++ is a big, complex language.  There is no
practical way to change that.

>- In "Effective C++ 3rd edition" you talk about TR1 in many places. 
>  What is TR1 and why is it important to C++ programmers?

TR1 is a technical report that specifies 14 new kinds of library
functionality that are all but certain to be added to the standard library
in C++0x.  Of those 14, 13 have already been voted into the draft for
C++0x, though it's likely that what ultimately gets into C++0x will differ
from what TR1 specifies in some ways.  That's because TR1 is limited to
using C++ as defined by the 1998/2003 standard, while the standard library
for C++0x can take advantage of any new language features that C++0x adds.

TR1 is important to C++ programmers, because it gives them a glimpse of
significant new functionality that should be part of every C++
implementation within the next few years. For those who want to start using
the functionality now, there are implementations of most TR1 components
available from places like Boost and STLPort.  Such implementations
sometimes differ from the TR1 specification, though generally in fairly
minor ways.

>- New hardware architectures and multithreaded programs will have new
>  requirements for C++ as language.  Is there any hope ? (I remember Sutters
>  Keynote ;-)

It appears very likely that C++0x will define a memory model, and that's
the foundation on which reliable cross-platform threaded execution can be
built. A memory model is directly relevant primarily to compiler and
library writers, but the impact will be felt by everybody who uses C++.
Having said that, I haven't heard anything that suggests that the set of
standard threading facilities available to end users is likely to rise
above what's currently available through libraries like Posix, so at this
point it doesn't seem likely to me that threaded programming in C++0x will
differ radically from threaded programming in current C++.  On the other
hand, I'm not on the standardization committee, so it's possible that they
will end up standardizing something much more ambitious.

>- Will there be a next book project (e.g. a book about keyholes ?) or a
>  CD-update for Effective C++? 

I'm always planning new books, but most of them never get written :-)
Still, I hope to write a new book next year, and one of the things on my
2007 "to do" list is to write up my keyholes work in some way.  That may be
a book, it may be something else, I don't know yet.

My publisher and I have talked about producing an updated electronic
version of my books to include the newest edition of Effective C++ as well
as Effective STL (which is not on the current CD).  We'd both like to do
it, but there are open questions regarding the format (e.g., HTML?  PDF?
Both?  Neither?).  I hope that those issues get resolved relatively soon so
that we can move forward on the project.

>- Do you plan to get into anything beside C++, yourself?

I've been doing the keyholes work as well as some language-independent work
on software quality, and I plan to continue to pursue those interests, but
I expect to remain very involved in C++.  I'm increasingly interested in
helping embedded programmers take advantage of C++, and I expect to do a
fair amount of work in that area in the future.