Programming 版 (精华区)

发信人: armstrong (小小), 信区: Programming
标  题: C++View Interviews Bjarne Stroustrup
发信站: 哈工大紫丁香 (2001年11月27日21:34:21 星期二), 站内信件

From http://www.research.att.com/~bs/01chinese.html

C++View Interviews Bjarne Stroustrup
This is the English language version of an interview of Bjarne Stroustrup by
 the Chines web magazine C++ View. You can find the Chinese-language version
 in the September 2001 issue (#003).
Related information:
more interviews
papers and books
general FAQ
C++ style and technique FAQ
C++ glossary
general C++ links, incl links related to the ISO C++ standard
----------------------------------------------------------------------------
----
C++ View: The ANSI/ISO standardization of C++ indicates that the C++ languag
e has matured. Would you please tell us the most unforgettable, the happiest
 and the most regrettable things you felt in the course of standardization?
Bjarne Stroustrup: Standardization is an extremely valuable, most important,
 largely underestimated, and most frustrating activity. C++ became a better 
language through standardization and acquired a standard library of surprisi
ng expressive power. Formal standardization is one of the few defenses that 
a user has against the interests of compiler suppliers, who always try to lo
ck in their users.
It's hard to pick out specific events. Most of the work in the committee has
 the form of a process of discovery, refinement, and building of trust. Such
 things take time. However, the single most important event must be either t
he initial 1990 vote to standardize C++ based on the reference manual of the
 2nd edition of "The C++ Programming Language" (that is, with templates and 
exception handling) or the final 1998 vote ratifying the ISO standard. In be
tween those events, the vote to accept the STL as part of the standard libra
ry standard stands out as a most happy event.
There is no negative/regrettable event of a magnitude to match these positiv
e votes. All "regrettable things" are either very minor technical details or
 discussions that (temporarily) polarized the committee so as to make furthe
r progress harder. I would have liked to deprecate C-style casts and not to 
introduce in-class initialization of static const members of integral types 
(only), but these are minor details.
I am looking ahead to yet another key vote. Sometime over the next year, the
 committee will decide on the future directions for ISO C++. That will be an
 event of the first magnitude.
C++ View: Why is the standardization of C++ frustrating? And would you pleas
e tell us more about the process of the work in the committee?
Bjarne Stroustrup: Standardization is a slow process, often focussed on minu
te technical details, and you need to get dozens of people from many countri
es and from very diverse technical cultures to agree. Also people representi
ng very different organizations (or just themselves) need to collaborate pro
ductively. The C++ committee is not an organization that is happy with a vot
e being "won" by a 60% to 40% margin. Such a vote would be considered a fail
ure. We aim for consensus, meaning "almost everybody agrees" and work until 
we reach that. That's hard, and everybody - at least sometimes - wish for a 
faster way. However, the result is a language that is acknowledged to be goo
d enough for an incredibly large community, rather than being just perfect f
or any one use or any one individual. In the end, we managed to get unanimou
s votes (43-0 in ANSI and 22-0 in ISO) for the standard. I have been told th
at this degree of agreement has never before been achieved for a programming
 language standard.
First the committee has to figure out what the real problems are and what ki
nd of technical solution is feasible. This, I referred to as "discovery". Ne
xt we have to refine that solution into something precisely described in sta
ndards text. And always the individuals taking part in the standards process
 must learn to work with each other and to trust the good intent and the pro
fessional abilities of others. That, I referred to as "building of trust" - 
it is quite possibly the most important single part of the standard process;
 without mutual trust nothing can be achieved.
C++ View: Alexander Stepanov said that once he had argued with you because h
e thought C++ template functions should be explicitly instantiated like Ada 
generics, while you insisted that functions be instantiated implicitly using
 an overloading mechanism. Thanks to your insistence, this particular techni
que later plays an important part in STL. Could you tell us more about this 
story?
Bjarne Stroustrup: I can't add much. Alex and I spent some time discussing l
anguage features before templates became part of C++. He was - in my opinion
 - at the time overly influenced by his experience with Ada, but he also had
 valuable practical experience with generic programming that I largely lacke
d. He reinforced my bias in favor of uncompromising efficiency and inlining.
 We both shared a dislike of macros and a liking for type safety. He would h
ave liked stronger static type checking of template arguments. So would I, b
ut didn't see a way of getting that without limiting what could be expressed
 or compromising efficiency. In particularly, I was - and am - very suspicio
us of attempts to limit template arguments to inheritance hierarchies.
Later, Alex used the template features I designed in innovative ways that le
d to the STL, and to the current emphasis on generic and generative programm
ing. Alex is alway fun to argue with! For an impression of his style, see an
 interview with Alex.
I experimented with ways of constraining template arguments without using la
nguage extensions. My early ideas are described in The Design and Evolution 
of C++ and later variations are part of the now common uses of constraints a
nd concept checking. These systems are far more expressive and flexible than
 built-in facilities found in other languages. For an example, see my C++ St
yle and Technique FAQ.
C++ View: Jerry Schwarz reviewed the history of IOStream in the preface of t
he book Standard C++ IOStream and Locales. I guess that there must be many i
nteresting stories in the process of transiting from classic stream into the
 standard IOStream. Can you tell us some?
Bjarne Stroustrup: I do not want to try to add to Jerry's description of the
 transition from my streams to the current iostreams. Instead, I'd like to e
mphasize that the original streams library was a very simple and very effici
ent library. I designed and built it in a couple of months.
The key decisions was to separate formatting from buffering, and to use the 
type-safe expression syntax (relying on operators << and >>). I made these d
ecisions after discussions with my colleague Doug McIlroy at AT&T Bell Labs.
 I chose << and >> after experiments showed alternatives, such as < and >, c
omma, and = not to work well. The type safety allowed compile-time resolutio
n of some things that C-style libraries resolve at run-time, thus giving exc
ellent performance. Very soon after I started to use streams, Dave Presotto 
transparently replaced the whole buffering part of my implementation with a 
better one. I didn't even notice he'd done that until he later told me!
The current iostreams library will never be small, but I believe that aggres
sive optimization techniques will allow us to regain the efficiency of the o
riginal in the many common cases where the full generality of iostreams is n
ot used. Note that much of the complexity in iostreams exist to serve needs 
that my original iostreams didn't address. For example, standard iostreams w
ith locales can handle Chinese characters and strings in ways that are beyon
d the scope of my original streams.
C++ View: It's said that Java is purely object-oriented, while C# is even mo
re. And many people say they are purely money-oriented. What's your opinion?

Bjarne Stroustrup: I like the term "money-oriented" :-) I also like Andrew K
oenig's phrase "buzzword-oriented". C++ is neither.
More to the point, I don't think "purity" is a virtue. The signal strength o
f C++ is exactly that it supports several effective styles of programming (s
everal paradigms, if you must), and combinations of these styles. Often, the
 most elegant, most efficient, and the most maintainable solution involves m
ore than one style (paradigm). If you must use fancy words, C++ is a multi-p
aradigm programming language. Given the wide variety of demands in the huge 
area of software development, there is a need for at least one general-purpo
se language supporting a range of programming and design styles, and probabl
y for more than one such language. Also, there is room for many programming 
languages in the world. The idea that a single language is best for every ap
plication and every programmer is absurd.
Java and C#'s main strengths are the support they receive from their owners.
 This implies a low price (implementations and libraries given away for free
 to gain market share), intensive and unscrupulous marketing (hype), and an 
appearance of a standard due to lack of alternative suppliers. However, when
, as in the case with Java, other suppliers and revised versions eventually 
appear, versioning, compatibility, and portability problems re-emerge, as wi
th other languages.
There is no substitute for formal standards, generated by an open process th
at is not manipulated by a language owner. A formal standards process, such 
as ISO's, is a user's only hope for a language that isn't jerked around for 
the benefit of it's owner or for the benefit of "average users" over the obj
ections of "minorities" deemed economically unimportant.
C++ could be simpler and easier to use ("purer, if you must), but not while 
still supporting users with "unusual" demands. I am personally very concerne
d to support people building systems with demands for reliability, run-time 
performance, and maintainability that are far greater than the industry aver
age. My conjecture is that over the span of a decade most programmers will f
ace "unusual" technical requirements that will benefit from C++'s multi-para
digm structure while not being well served by "simplified" languages such as
 Java and C#.
I consider templates and generic programming central to modern C++. They are
 the keys to uncompromisingly efficient, type-safe code. However, they don't
 fit the classical object-oriented paradigm.
C++ View: In the book C++??: A Critique of C++ and Programming and Language 
Trends of the 1990s, Ian Joyner compared C++ to Java and Eiffel and criticiz
ed many mechanisms of C++. Do you agree with him? Especially, most new langu
ages has a garbage collection mechanism. Will it be added to C++?
Bjarne Stroustrup: No. I don't agree with Ian Joyner about C++. Independentl
y of that, garbage collection can be a valuable technique, but it is not a p
anacea and it can also cause problems. Automatic garbage collection is a val
id implementation technique for C++. Good garbage collectors exist for C++ (
both commercially supported and free) and are widely used (see links on my C
++ page). However, garbage collection is optional in C++ so that application
s for which GC is unsuitable, such as hard real time applications, aren't bu
rdened by it. See my comments about GC in The C++ Programming Language (3rd 
Edition) and on my home pages.
I expect that the next C++ standard will explicitly state roughly what I jus
t said above and elsewhere.
In this context, it is worth noting that C++ has support for elegant techniq
ues for handling resources in general, and not just memory. In particular, t
he "resource acquisition is initialization" technique (see D&E, TC++PL3, and
 my technical FAQ) supports simple, exception-safe management of arbitrary r
esources. Since Java lacks destructors it cannot support that technique.
C++ View: STL is an excellent cross-platform framework. Have you considered 
designing such standard frameworks on other aspects, GUI for example?
Bjarne Stroustrup: Naturally. Many have wondered how to replicate STL's succ
ess in other areas. For example, interesting work has been done in numerics 
and for graphs. See my C++ page for links.
A standard GUI would be of immense value, but I doubt that it is politically
 feasible. Too many rich companies have serious commercial interests in main
taining their proprietary GUIs. Also, users cannot easily change from what t
hey are currently using.
What I refer to is what is commercially and technically feasible. There are 
several very widely used GUIs. They won't just go away if a standards commit
tee decided on an alternative. Their owners and their users would - often fo
r good reasons - simply ignore a new standard. Worse: some company or group 
of people might actively oppose such a standard because they considered it i
nferior to what they already had or simply too different for a switch to the
 new GUI to be feasible. It is important to understand that if a standard do
esn't adequately serve its intented user, then those users will simply ignor
e them. Many ISO standards are irrelevant because nobody follow them. The C+
+ standard is not one of those - it is doing immeasurable good by pulling th
e implementations closer together - and we don't want the ISO C++ standard t
o be an ignored standard in the future.
Note that one major reason that the STL succeeded was that it was a technica
l breakthrough. It wasn't simply "yet another container library", so it didn
't have to compete directly against the many existing container libraries (s
everal of which were of excellent quality). My guess is that for C++ to get 
a standard GUI, we need a technical breakthrough plus a lot of luck.
However, I still doubt that the committee has the technical expertise and th
e resources necessary to produce a GUI that could become a real standard in 
the real world.
My thoughts for the standard library goes more towards filling in gaps in th
e current library (e.g. hash_map and regular expressions) and support for di
stributed computing through more extensive (optional) run-time type informat
ion and concurrency libraries.
People sometime forget that a library doesn't have to be part of the standar
d to be useful. There are thousands of useful C++ libraries. For example, se
e the C++ libraries FAQ.
C++ View: Generic programming is a special paradigm in C++. What do you thin
king of GP and OO? Will C++ provide more powerful mechanisms to support GP i
n the future? And have you considering importing other paradigms, pattern-or
iented for example?
Bjarne Stroustrup: I think that object-oriented programming and generic prog
ramming complements each other nicely in C++, and many of my most elegant pi
eces of code relies on combinations of the two. That is, it is wrong to thin
k of OOP and GP as completely distinct paradigms. They are techniques that s
hould be used in combination, and a language should support such combination
s - as C++ does.
I think that C++ supports generic programming rather well, so that it needs 
only minor additions. An obvious example is templated typedefs. We have to b
e careful to extend the language only where extensions provide major advanta
ges in what can be expressed. For example, I don't support ideas of direct l
anguage support for template argument constraints checking. We can already d
o more with constraints/concept checking templates than could be done with t
he various language extensions proposed for C++ and similar languages.
I'm very reluctant to talk about "paradigms" and "new paradigms" - very few 
ideas deserve such fancy terms. I also worry that too direct support of new 
ideas can be limiting and failing to cater for further evolution of our idea
s and our techniques. Ideally, language facilities should support very gener
al ideas efficiently so that people can use those facilities to write code i
n a variety of styles. I think that it remains to be seen what patterns idea
s can and cannot be supported elegantly through a combination of styles alre
ady supported in C++. I suspect that very few new language concepts are need
ed specifically to support patterns.
C++ View: Will C++ support the disturbed development later? And what about f
urther support for RTTI and multi-thread?
Bjarne Stroustrup: Yes. If things progress as I hope they will, the next rev
ision of the C++ standard will support distributed computing through the pro
vision of extended type information and concurrency-support libraries. I do 
not think this will require specific language extensions. Making additional 
guarantees about the implementation of existing language facilities in the p
resence of concurrency will be needed, though.
There is not much that I can add to that now, because the discussions about 
what should and should not be in the next standard have just started. My vie
w is that C++ need a standard library that seemlessly support threads (withi
n a single address space), processes (with separate address spaces), and rem
ote processes (where communication delays can be significant and where a net
work may become separated for a while). Supporting this will require facilit
ies beyond simple Unix or Windows threads. However, I don't think it need in
volve new language primitives.
C++ View: Recently a new project called YASLI which stands for "Yet Another 
Standard Library Implementation" has been started, that intents to be the ne
w generation of C++ Standard Library implementation. What do you think about
 it?
Bjarne Stroustrup: I don't know enough about that project to have an opinion
.
C++ View: It's believed that great men would show their differences against 
others when they are young. So what differences did you show when studying i
n the universities?
Bjarne Stroustrup: I'm not sure anyone considered me as significantly differ
ent from others. I suspect that I was a bit more naive and idealistic than m
ost. I also spent more time working of practical problems than most - to ear
n money to avoid getting into debt. Not building up debt was important for m
e because I don't come from a rich family. I have been told that I worked ha
rd. On the other hand, I tended to work on a variety of things that interest
ed me (including philosophy and history) rather than just on things that dir
ectly helped me finish my degree or improve my grades.
C++ View: Do you like reading Andersen's fairy stories? He wrote something a
bout China in the story of The Nightingale. So what's your impression about 
China, the Chinese culture and the Chinese people? Have you ever been to Chi
na before? Maybe visiting China for the Olympics in 2008 would be a good ide
a.
Bjarne Stroustrup: As a Dane, I naturally know Hans Christian Andersen's tal
es. I also happen to like them. The China described in "The Nightingale" is 
a fiction that may or may not have anything to do with the China that then e
xisted. Andersen created that "China" to be able to make universal points ab
out countries and their rulers.
It is hard to have one impression about something as huge as China. The Chin
ese that I have met are mostly programmers or engineers, so I probably have 
a misleadingly narrow view of Chinese people. Even a small country and cultu
re as my native Denmark is too complex for any individual to fully comprehen
d - and there are only 5 million Danes. I have a strong interest in history,
 so I have read several books on Chinese history and culture. However, that 
implies that ancient China may loom larger in my mind than it should compare
d to modern China. I lectured in Taiwan for a week and enjoyed my stay there
, but I have not yet had the opportunity to visit the mainland.
I have read many books about Chinese history and culture. Because of the len
gth of Chinese history and the size of China, most focus on events, people, 
and traditions of earlier times, and hardly any describe China as it has bee
n for the last ten or 20 years. I know from the news and from Chinese friend
s that major changes have happened and that my ignorance of current-day Chin
a is immense (though probably not as immense as most people's ignorance abou
t far-away countries). For example, I have no idea of current Chinese litera
ture or music. Thus, when I think of China, some of what I think may be seri
ously out of date - despite the care I obviously take to avoid such mistakes
. By the way, I have similar problems for other regions of the world that I 
also know of primarily from books.
I'm not keen on huge crowds and organized mass events, so I'll stay far away
 from the 2008 Olympics, just as I stayed away from every other Olympic game
s that I might have attended. I hope to find some other time to visit China.



--
Everybody believes that children are true,
women are beautiful and
men are strong.

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: 202.118.236.207]