|
The first five questions were submitted by Brad from Gilbert,
AZ:
1. What do you see as the future of C++, and where will
it fit in the future of computer science?
I view C++ as the language of choice for what I call "demanding
systems applications." Such applications face one or more constraints
that are difficult to meet. Often, the constraint is on performance
(e.g., the software must be as fast as possible), sometimes it's
on space (e.g., it must fit within limited memory), sometimes it's
on control (e.g., the application must communicate directly with
hardware). Such applications have traditionally been the domain
of C, but I think that C++ will continue to gain ground here.
Industries where such applications are common include embedded
systems, games, financial analysis, and simulations. For many applications
in such industries, reducing program runtime is more important
than reducing programmer development time (though that is important,
too), so C++ has an edge over "productivity languages" like Java
and C#.
As for C++'s role in computer science, I think that C++ will continue
to be an important testbed for ideas in multiparadigm programming
and in template metaprogramming and related technologies (e.g.,
expression templates).
2. What language would you recommend be used to teach
programming to new CS students?
My language expertise is limited to C++, and I don't really know
enough about the pros and cons of competing languages to make an
informed evaluation. Having said that, my feeling is that a first
language should foster a feeling of power and accomplishment out
of the box — it should get people excited about the limitless
things that can be accomplished in software. Among other things,
such a language would offer an extensive and powerful library,
so that complex tasks such as navigating the internet or putting
up GUIs would be easily accomplished.
Candidate languages that come to mind would be Java, C#, and Python.
Neither C nor C++ offers sufficiently powerful libraries to be
good candidates for a first language, in my opinion. When it comes
to systems programming, they're great (C++ is greater :-}), but
I don't think that introducing programming through systems applications
is the best approach for the majority of new students.
3. Every language has its flaws. What are the three things
you dislike most strongly in C++?
I'd like to answer this question with "complexity, complexity,
complexity!", but naming the same thing three times is cheating.
Still, I think that C++'s greatest weakness is complexity. For
almost every rule in C++, there are exceptions, and often there
are exceptions to the exceptions. For example, const objects can't
be modified, unless you cast away their constness, in which case
they can, unless they were originally defined to be const, in which
case the attempted modifications yield undefined behavior.
As another example, names in base classes are visible in derived
classes, unless the base class is instantiated from a template,
in which case they're not, unless the derived class has employed
a using declaration for them, in which case they are.
Such complexity affects more than just people who write programs
in C++. It also affects people who want to write tools that analyze
C++ programs. One of the reasons why there is a relative dearth
of tools such as refactoring browsers for C++ is that C++ is just
so darned complicated.
A related aspect of C++ I dislike has to do with what I perceive
to be an attitude on the part of the standardization committee
that such complexity is not a problem. I suspect that many members
of the committee would object to my characterizing their attitude
that way, but I'm talking only about my perception of their
attitude. I know that the people on the committee work hard to
make C++ as good as it can be. I also know that there are proposals
before the committee whose goal is to simplify C++. Still, my impression
is that the committee as a whole is unsympathetic to arguments
that C++ has become too complex, and I find that frustrating.
The third weakness of C++ I'd list is one I mentioned above:
its standard library is comparatively limited. I often say that
the "hello world" program for authors approaching a new language
is one that goes to Amazon, looks up the sales rank of one or more
books they wrote, then graphs the sales ranks over time. This is
easy to do with C# and Java, because they have libraries that make
grabbing URLs and producing graphs easy. In C++, it's a lot harder,
because such library functionality is missing.
4. A lot of CS work is being done on the web now; how
does C++ fit into web development?
Because I believe that C++ is the language of choice for demanding
systems applications, I'd expect that in the web realm, C++ would
be a good fit for web servers, database query optimizers, even
runtime program optimizers. I can't help but take some satisfaction
in knowing that the hotspot JVM is largely written in C++ :-)
5. What's your dream?
My dream is not having to work for a living, but that's a pretty
common dream, so I'll pick one that is probably less familiar.
As a user, my experience with commercial software and commercial
software companies is not very satisfactory. I find that many programs
have what I consider to be serious problems in usability, functionality,
or robustness, and that the companies that make the programs demonstrate
little interest in addressing these shortcomings.
My dream is for a revolution in the quality of end-user software
to rival the revolution in the quality of automobiles that took
place in the 1970s when Japanese automobiles began to make serious
inroads into the American market. I think that there has already
been something of a revolution of this nature in the server environment,
thanks to the challenge mounted by Linux, and I hope that an analogous
revolution takes root on the desktop.
However, the revolution has to take place in more than just the
software itself. The companies behind the software have to change,
too. As long as we have to make long-distance phone calls for technical
support to software companies that put us on hold and play recordings
telling us how important our calls are while simultaneously doing
everything they can to avoid having a human being talk to us, my
dream remains unfulfilled.
The following five questions were submitted by Vainstein from
California:
0. Do you see C++ ever getting simpler? Dropping features,
prohibiting co-use of certain features, etc.?
I don't think there is any practical way that C++ can get meaningfully
simpler. Any change to the rules of C++ that is not backwards-compatible
will face tremendous resistance in the standardization committee,
and I think this is proper: it's bad policy to make changes that
break programs that are currently legal, and it's even worse for
the semantics of legal programs to be modified, i.e., for "silent" changes
to be foisted on developers.
Even if the committee decided to deprecate some language features,
the process would take years, and there would be significant pressure
on vendors to continue to support the deprecated features, anyway.
After all, a vendor who removes a feature can only irritate existing
customers, whereas leaving the feature intact and possibly issuing
an optional warning allows them to follow the letter of the law
without enforcing its spirit.
As I mentioned above, there are some proposals before the committee
to simplify what I call "little things," (e.g., automatically declaring
a destructor virtual in a base class if the class already has virtual
functions), but such changes are window dressing. There's no practical
way to simplify the more fundamental issues I mentioned above (e.g.,
when const means const and when base class names are inherited
in derived classes). C++ wasn't designed to be simple, and I don't
see any practical way to retrofit simplicity onto it now.
1. Do you think C++ compilers could evolve to give errors
if a programmer does stuff like return a reference from a function?
They clearly could, the question is whether they will.
I've spent a number of years studying static analysis, and I've
concluded that compiler writers view their job as generating good
object code from valid source code. Along the way, they may issue
warnings, but issuing warnings isn't really their purpose, and
they do it with some reluctance. After all, they know that some
clients require warning-free compilations, and they also know that
in real programs, it's sometimes necessary to bend or break the
rules of good programming in order to get the job done. This means
that every additional warning they offer may make somebody's job
harder, so they tend to be conservative with what they warn about.
People who want more extensive static analysis can often turn on
compiler warnings that are disabled by default, but if you want
really good static analysis, you want an independent lint-like
tool that does nothing but look for suspicious coding constructs.
Several vendors offer such tools for C++.
2. What do you think of Java? For me, one of the best
things in Java is separate mechanisms for subclassing and for
subtyping — do you think this would be helpful in C++?
I don't have any general comments about Java, because I don't
really know it. (For the most part, my knowledge of Java and C#
is as deltas from C++.)
As for subclassing vs. subtyping, I assume you're referring to
inheritance vs. interfaces, and I haven't seen any groundswell
of support for adding interfaces to C++. Essentially the same behavior
can be achieved with the disciplined use of abstract base classes,
and I expect it'd be a hard sell to convince the C++ community
that they need another inheritance-like mechanism. I have seen
some people arguing for such a feature, but, as far as I know,
it's not on the list of features likely to be seriously considered
for the next version of C++. However, it's my understanding that
Microsoft's .NET version of C++ (C++/CLI) supports interfaces,
though, again, I have no reason to believe that this feature will
be added to standard C++.
3. What would you have to say to battle-worn industry
managers who forbid use of any C++ features except the single-line
comment?
I guess I'd point out that that means they're programming C, then
I'd ask them if they're sure that's really the best language for
their applications in 2005. If they said yes, I'd leave it at that,
but if they hesitated, I'd ask them how long ago their C++ battles
took place. Many people think that C++ and C++ compilers haven't
changed in a decade, but they've actually changed quite a bit.
Many battle-worn managers owe it to themselves to take a fresh
look at C++.
4. Do you plan to get into anything beside C++, yourself?
In terms of software, I've been into other things for quite some
time. A few years ago, I started work on what I call "The Keyhole
Problem," which is an examination of the problems that arise in
software from the inappropriate use of constraints. Work on that
project has been on the back burner during preparation of the third
edition of Effective C++, but I encourage people to take
a look at the web site for the keyhole problem, http://www.aristeia.com/TKP/index.htm.
My overarching interest is in ways to improve software quality,
regardless of the domain of the application, the language in which
it's written, the platform on which it runs, or the users it is
intended to serve. The keyhole problem is one reflection of this
interest, but so is my work in C++, because it's all about how
to improve the quality of the software you write. Recently, I've
been trying to identify methods and practices that yield better
software across the board. The primary result so far is a one-day
seminar I give on the topic (cf. http://www.aristeia.com/betterSoftware_frames.html),
but there's also a short article on part of that material (http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004.pdf).
Last year Andrei Alexandrescu and I co-authored an article in Dr.
Dobbs Journal on how the possibility of compiler
and hardware optimizations can affect the correctness of multithreaded
C++ programs (cf.
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004.pdf).
Next-generation hardware architectures will place a much greater
emphasis on multithreading to achieve
high performance, so I've become interested in threading issues.
It would not be hard to imagine writing a book on this topic,
but that's one of the problems with being an author: after a
while, everything looks like a book opportunity :-)
I've also been threatening for nearly a decade to write a book
that my parents can understand — something nontechnical.
I'd really like to do that, and in fact I hope to start this year.
However, I always have much more to do than time in which to do
it, so there's no telling what I'll get done in the next few months.
However, it's fair to say that it will encompass more than just
C++ stuff.
|
C++
Scott
Meyers is one of the world's foremost experts on C++ software
development. He is author of the best-selling Effective C++ series (