C++之父（Bjarne Stroustrup）给C++初学者的信

C++之父（Bjarne Stroustrup）来信，我们怎么学习C++，让我们一起来看看吧

From: [e-mail] (Bjarne Stroustrup) 

Newsgroups: comp.os.msdos.programmer, 

comp.sys.ibm.pc.programmer, 

comp.lang.c++,comp.lang.c 

Subject: Newbie Wants Advice on C-Programming 

Summary: general comments on learning C++ 

Date: 29 Dec 92 17:52:53 GMT 

Organization: AT&T Bell Laboratories, Murray Hill NJ 

Lines: 288 

There has - under various headings - been several related discussions about the proper way to learn C++, C++'s relation to C, C++'s relation to Smalltalk, the difference (or not) between data abstraction and object-oriented programming, etc.

虽然标题各不相同，但已经有过好几个与学习C++相关的讨论话题，像是C++与C的 关联、C++与Smalltalk的关联、资料抽象化与物件导向程式设计之间的差异（或者不同点）等等。 

I think the practical concern underlying many of these discussions is: 

Given that I don't have much time to learn new techniques and concepts, how do I start using C++ effectively?

我想在这许多讨论中实际上关心的是： 

如果我没有太多的时间来学习新的技术或观念，初学C++的话怎么样才比较有效率？ 

It is clear that to use C++ ``best'' in an arbitrary situation you need a deep understanding of many concepts and techniques, but that can only be achieved through years of study and experiments. It is little help to tell a novice (a novice with C++, typically not a novice with programming in general), first to gain a thorough understanding of C, Smalltalk, CLOS, Pascal, ML, Eiffel, assembler, capability based systems, OODMBSs, program verification techniques, etc., and then apply the lessons learned to C++ on his or her next project. All of those topics are worthy of study and would - in the long run - help, but practical programmers (and students) cannot take years off from whatever they are doing for a comprehensive study of programming languages and techniques.

很显然的，要让C++在任意的场合中都能好好的发挥，对许多的观念与技术都要有深刻 的瞭解，但这是要长年的研究与经验才能够得到的。所以以下的说词对初学者（一般来说，基本上一个C++初学者并不一定是程式设计上的初学者）是没什么用 的：「首先要对C、Smalltalk、CLOS、Pascal、ML、Eiffel、assembler等等有个彻底的认识，然后将在C++课程上所学 到的东西，应用至下一个专桉中。」上面所提及的几个主题都值得研究，而且最后一定会有帮助，但是实务性为主的程式设计人员（与学生）没办法抛开目前目前手 上的工作，然后花上好几年的时间来彻底研究这些程式语言与技术。 

On the other hand, most novices understand that ``a little knowledge is a dangerous thing'' and would like some assurance that the little they can afford time to learn before/while starting their next project will be of help and not a distraction or a hinderance to the success of that project. They would also like to be confident that the little new they can absorb immediately can be part of a path that can lead to the more comprehensive understanding actually desired rather than an isolated skill leading nowhere further.

另一方面，大部份的初学者都瞭解到「一知半解是很危险的」，他们希望能够保证在开始 下一个（或正在进行的）专桉中，目前所付出的这些时间最好是有帮助的，而不是一种困扰或妨碍。他们也需要确定所学到的这些新知，将来是可以成为广泛应用的 技术，而不只是个将来不再使用的封闭技巧。

Naturally, more than one approach can fulfill these criteria and exactly which to choose depends on the individual's background, immediate needs, and the time available. I think many educators, trainers, and posters to the net underestimate the imporatance of this: after all, it appears so much more cost effective - and easier - to ``educate'' people in large batches rather than bothering with individuals.

自然的，有很多方法可以符合这些考量，至于选择哪一种方法必须依据个人所拥有的背 景、立即性需求以及可运用的时间来决定。我想许多教育训练人员以及海报都低估了这些元素的重要性：毕竟，这要花费许多心力才能看出效果：毕竟批次的教导人 员总是比为了个桉而烦恼来得轻鬆多了。 

Consider a few common questions: 

I don't know C or C++, should I learn C first? 

I want to do OOP, should I learn Smalltalk before C++? 

Should I start using C++ as an OOPL or as a better C? 

How long does it take to learn C++?

想想几个常见的问题： 

我不懂C或C++，要不要先学C呢？ 

我要进行OOP（物件导向程式设计），需不需要在学C++之前先学 Smalltalk？ 

我应该将C++当作OOPL（物件导向程式设计语言）吗？或只是一个"更好的C"？ 

学C++要花多久的时间？ 

I don't claim to have the only answers ``the (only) right answers'' to these questions. As I said the ``right'' answer depends on the circumstances. Most C++ textbook writers, teachers, and programmers have their own answers. For example, I seem to remember that the C++ FAQ discusses these questions. My answers are based on years of programming in C++ and other languages, teaching short C++ design and programming courses (mainly to professional programmers), consulting about to introduction of and use of C++, discussing C++, and generally thinking about programming, design, and C++.

我不想宣称只有唯一的答桉，"对这些问题唯一且正确的的答桉"。要我说的话，正确的 答桉要看情况。大部份C++书本的作者、老师与程式设计人员都有他们自己的答桉，例如，我依稀记得C++ FAQ讨论过这些问题。我的答桉则是基于多年来的C++程式设计经验、对其它的语言的瞭解、短期的C++设计教学与程式设计课程（主要是对专业的程式设计 人员）、C++的使用资询与简介、C++的讨论、以及常常地想着写程式、设计与C++。 

I don't know C or C++, should I learn C first?

我不懂C或C++，要不要先学C？ 

No. Learn C++ first. The C subset of C++ is easier to learn for C/C++ novices and easier to use than C itself. The reason is that C++ provides better guarantees than C (stronger type checking). In addition, C++ provides many minor features, such as the `new' operator, that are notationally more convenient and less error-prone than their C alternatives. Thus, if you plan to learn C and C++ (or just C++) you shouldn't take the detour through C. To use C well, you need to know tricks and techniques that aren't anywhere near as important or common in C++ as they are in C. Good C textbooks tends (reasonably enough) to emphasize the techniques that you will need for completing major projects in C. Good C++ textbooks, on the other hand, emphasizes techniques and features that lead to the use of C++ for data abstraction and object-oriented programming. Knowing the C++ constructs, their (lower-level) C alternatives are trivially learned (if necessary).

不！先学C++。C++的C子集对于C/C++初学者来说是比较容易，而使用C本身 确实比较容易，原因在于C++提供了比C（强型别检查）更多安全性。除此之外，C++还提供了许多小特性，像是"new"运算子，这明显的比C中相对应的 功能更方便且更能避免错误，因此，如果您想要学C与C++（或只要C++），您不用迂迴的从C开始学起，要把C用的好，您会需要知道一些技巧与技术，而这 些在C++中并不会像在C中一样的重要与常见，好的C教科书会特意强调完成一个使用C的专桉时所需要的技术（这相当合理），然而另一方面，好的C++教科 书则强调一些技术与特性，C++的这些技术与特性会将重点放在资料抽象化与物件导向程式设计。瞭解了C++的建构，在（低层次的）C的相对应部份自然也会 学起来了（如果有需要的话）。 

To show my inclinations:

To learn C use:

我个人的倾向则是： 

要学C的话，使用下面这一本书作为主要教科书： 

Kernighan and Ritchie: 

The C programming Language (2nd edition) 

Prentice Hall, 1988. 

To learn C++ use:

要学C++的话用这本：

Stroustrup: 

The C++ programming Language (2nd edition) 

Addison Wesley, 1991. 

Both books have the advantage of combining a tutorial presentation of language features and techniques with a complete reference manual. Both describes their respective languages rather than particular implementations and neither attempts to describe particular libraries shipped with particular implementations.

这两本都结合了程式语言教学与技术参考手册的优点，它们说明了各自的语言而不是特定 的实作，而且并没有试图叙述一些使用在特殊用途上的特定函式库。 

There are many other good textbooks and many other styles of presentation, but these are my favorites for comprehension of concepts and styles. It is always wise to look carefully at at least two sources of information to compensate for bias and possible shortcommings.

还有许多其它不错的教科书与呈现方式，但对于在观念与风格上的通盘瞭解来看的话，这些是我的最爱。详细的看过两个以上的资讯来源总是明智的，以在一些可能 的缺点上或偏颇上能够互补。

I want to do OOP, should I learn Smalltalk before C++?

我要作OOP，要在学C++之前先学Smalltalk吗？ 

No. If you plan to use C++, learn C++. Languages such as C++, Smalltalk, Simula, CLOS, Eiffel, etc., each has their own view of the key notions of abstraction and inheritance and each support them in slightly different ways to support different notions of design. Learning Smalltalk will certainly teach you valuable lessons, but it will not teach you how to write programs in C++. In fact, unless you have the time to learn and digest both the Smalltalk and the C++ concepts and techniques, using Smalltalk as a learning tool can lead to poor C++ designs.

不！如果您想要学C++，就学C++。像C++、Smalltalk、 Simula、CLOS、Eiffel等的程式语言，对于抽象、继承等上，每一个都有各自的观点，而这些程式语言在支援不同特性的设计上都会有一些差异， 学习Smalltalk当然会得到不少宝贵的课程，但是它并不会告诉您如何使用C++撰写程式，事实上，除非您有时间学习与探索Smalltalk与C+ +的观念与技术，利用Smalltalk作为学习工具，在C++的设计上并没有太大的帮助。

Naturally, learning both C++ and Smalltalk so that you can draw from a wider field of experience and examples is the ideal, but people who haven't taken the time to digest all the new ideas often end up ``writing Smalltalk in C++'' that is applying Smalltalk design notions that doesn't fit well in C++. This can be as sub-optimal writing C or Fortran in C++.

当然，C++与Smalltalk两个都学，您可以从更广的领域中得到更多的经验与 实证，这是最理想的，但是人们在还没有时间消化所有的新想法时，最后通常会变成"在C++中写Smalltalk"，也就是说将Smalltalk设计中 一些不是很符合C++特性的部份加以套用，这就如同在C++中写C或者是Fortran一样的不理想。

One reason often quoted for learning Smalltalk is that it is ``pure'' and thus force people to think and program ``object oriented.'' I will not go into the discussion about ``purity'' beyond mentioning that I think that a general purpose programming language ought to and can support more than one programming style (``paradigm'').

常见到的学习Smalltalk的理由是，它很"纯綷"，并且可以迫使人们以物件导 向的方式思考与设计程式。我不想讨论"纯綷"而不提到：我认为一个通用型的程式语言，应该且能支援一种以上的程式设计风格（模式）。 

The point here is that styles that are appropriate and well supported in Smalltalk are not necessarily appropriate for C++. In particular, a slavish following of Smalltalk style in C++ leads to inefficient, ugly, and hard to maintain C++ programs. The reason is that good C++ requires design that takes advantage of C++'s static type system rather than fights it. Smalltalk support a dynamic type system (only) and that view translated into C++ leads to extensive unsafe and ugly casting.

这边的观点在于，Smalltalk支援的一些不错的风格，在C++中不一定适合， 在C++中毫无创意的遵从Smalltalk的风格，将会导致没有效率、不良，并使得C++程式难以维护，原因在于好的C++要利用到C++静态型别系统 的设计，而不是抗拒它。Smalltalk（只）支援动态型别系统，而这些观点转移至C++将会导致广泛的安全性问题与丑陋的型态转换。 

I consider most casts in C++ programs signs of poor design. Some casts are essential, but most aren't. In my experience, old-time C programmers using C++ and C++ programmers introduced to OOP through Smalltalk are among the heaviest users of casts of the kind that could have been avoided by more careful design.

我认为在C++程式中大部份的型态转换都是不良设计的表现，有一些转型是必要的，但 大部份并不是如此，以我的经验中得知，一些以前使用C的C++程式设计人员，以及从Smalltalk进入OOP世界的人，都是这种型态转换的使用者，而 他们是可以透过更细心的设计来避免（这些不良设计）的。 

In addition, Smalltalk encourages people to see inheritance as the sole or at least primary way of organizing programs and to organize classes into single-rooted hierarchies. In C++, classes are types and inheritance is by no means the only means of organizing programs. In particular, templates is the primary means for representing container classes.

除此之外， Smalltalk鼓励人们将继承视作是组织程式的灵魂，或至少是主要的方法，且将类别组织为单根的体系。在C++中，类别是型别，而继承无论如何都不可 能是组织程式的唯一方法，特别的是，范本是展现容器类别的主要方法。 

I am also deeply suspicious of arguments proclaiming the need to FORCE people to write in an object-oriented style. People who don't want to learn can, on average, not be taught with reasonable effort and there is in my experience no shortage of people who DO want to learn. Unless you manage to demonstrate the principle behind data abstraction and object-oriented programming all you'll get is inappropriate ``barouque'' misuses of the language features that support these notions - in C++, Smalltalk, or whatever.

我也相当的怀疑那些宣称人们必须以物件导向风格撰写程式的论调。对于不想学习的人要 教导其付出必要的努力是没办法的，而就我的经验来说，这种不想学习的人不少。除非您想强调在资料抽象化与物件导向程式设计背后的规则，否则您只会将C+ +、Smalltalk，或其它支援这些概念的语言特性，作不适当的"巴洛克式"误用。

See ``The C++ Programming (2nd Edition)'' and in particular Chapter 12 for a more thorough discussion of the relation between C++ language features and design.

看看"The C++ Programming (2nd Edition)"，尤其是在第12章有关于C++特性及设计的更多讨论。

Should I start using C++ as an OOPL or as a better C?

在开始使用C++时，我要将之当作OOPL？还是"更好的C"？ 

That depends. Why do you want to start using C++? The answer to that question ought to determine the way you approach C++; not some one-size-fits-all philosophy. In my experience the safest bet is to learn C++ ``bottom up,'' that is first learn the features C++ provides for traditional procedural programming, the ``better C'' sub-set, then learn to use and appreciate the data abstraction features, and then learn to use class hierarchies to organize sets of related classes.

得看情况，为什么您要开始用C++呢？问题的答桉可以决定您如何使用C++，这不是 可以全部套用的哲学。以我的经验来说，最安全的押注方式是"由下往上"学习C++，也就是说先学习C++在传统程序设计上所提供的特性 - "较好的C"子集，然后学习使用与理解资料抽象化的特性，并且学习使用类别体系以组织相关的类别集合。 

It is - in my opinion - dangerous to rush through the earlier stages because there is too high a probability of missing some key point.

以我的观点来说，急急忙忙略过初阶部份相当的危险，因为很有可能忽略关键的部份。 

For example, an experience C programmer might consider the ``better C'' subset of C ``well known'' and skip the 100 pages or so of a textbook that describes it. However, in doing so he might miss the ability to overload functions, the difference between initialization and assignment, the use of the `new' operator for allocation, the explanation of references, or some other minor feature in such a way that it will come back to haunt him at a later stage where sufficient new concepts are in play to complicate matters. If the concepts used in the better C subset are known the 100 pages will only take a couple of hours to learn and some details will be interesting and useful. If not, the time spent is essential.

例如，一个有经验的C程式设计人员可能自认为熟悉C"，因而误以为熟知C++中"较 好的C"子集，并跳过书本中描述这部份的100或更 多页，然而，这么作之后，他可能忽略了函式重载的能力、配置时new 运算子的使用、参考的解说、或一些其它的小特性，以至于之后他还必须回想这些複杂东西在那边曾经出现过。如果已经知道较好C子集的观念，这100页只会花 上您几个小时来学习，且有些细节是有趣且有用的，如果不是的话，则所花费的时间就是必要的。 

Some people have expressed fear that this ``gradual approach'' leads people to write in C style forever. This is of course a possible outcome, but nowhere as likely as proponents of ``pure'' languages and proponents of the use of ``force'' in teaching programming like to believe. The key thing to realize is that using C++ well as a data abstraction and/or object-oriented language requires the understanding of a few new concepts that have no direct counterpart in languages such as C and Pascal.

有些人表示，他们怕这种"渐进方法"会导致人们都使用C的风格来写程式，这当然是有 可能的，但现在是"纯綷"程式语言的支持者，与教导程式使用的支持者的问题，关键点在于必须瞭解，要将C++好好发挥在资料抽象化与（或）物件导向程式语 言上，就必须要瞭解一些新的观念，而这些新观念与一些语言，在像C与Pascal之类的语言并没有直接的关联。 

C++ isn't just a new syntax for expressing the same old ideas - at least not for most programmers. This implies a need for education, rather than mere training. New concepts have to be learned and mastered through practice. Old and well-tried habits of work have to be re-eva luated, and rather than dashing of doing things ``the good old way'' new ways have to be considered - and often doing things a new way will be harder and more time-consuming than the old way - when tried for the first time.

C++不仅仅是表现一些老旧主意的新语法，至少对多数的程式设计人员来说不是，这需 要一些教育，而不只是训练。新观念必须要学习并透过练习来主导，在工作上旧有且良好的经验习惯必须要重新提升，而不是作一些"旧有良好方法"之延伸，新的 方法必须要考虑进去，而在第一次试着使用时，每次都用新的方法会困难的多，而且比使用旧方法花费更多的时间。 

The overwhelming experience is that taking the time and making the effort to learn the key data abstraction and object-oriented techniques is worth while for almost all programmers and yields benefits not just in the very long run but also on a three to twelve month timescale. There are benefits in using C++ without making this effort, but most benefits requires the extra effort to learn new concepts - I would wonder why anyone not willing to make that effort would switch to C++.

绝大多数的经验是，花费时间与努力来学习关键的资料抽象化与物件导向技术，对大多数 的程式设计人员绝对是值得的，而产生的效益不仅仅是在最后，且持续三到十二个月的时间。在使用C++时是有一些不费力即可得到的好处，但大多数的益处是需 要额外的努力来学习新观念。我质疑的是，为什么有人不想附出这些心力就想转换至C++。 

When approaching C++ for the first time, or for the first time after some time, take the time to read a good textbook or a few well chosen articles (the C++ Report and the C++ Journal contain many). Maybe also have a look at the definition or the source code of some major library and consider the techniques and concepts used. This is also a good idea for people who has used C++ for some time. Many could do with a review of the concepts and techniques. Much has happened to C++ and its associated programming and design techniques since C++ first appeared. A quick comparison of the 1st and the 2nd edition of ``The C++ Programming Language'' should convince anyone of that.

第一次接触C++时，或者是在某个时间之后又再度接触C++，请花时间看一本好书， 或者是一些精选的文章（C++ Report与C++ Journal Contain中有很多），也许看看一些主函式库的定义与原始码，并考虑所使用的观念与技术，这对于过去曾经使用过C++的人也是个不错的主意，这可以对 观念与技术作一个複习，在C++第一次出现之后，中间C++又发生了许多事，而相关的编程与设计技术也有了改变，比较一下"The C++ Programming Language"第1版与第2版的差别，任何人都会相信这点。 

How long does it take to learn C++?

学习C++要花多久的时间？ 

Again, that depends. It depends both on your experience and on what you mean by ``learning C++.'' The syntax and basics for writing C++ in the better C style plus defining and using a few simple classes takes a week or two for a programmer. That's the easy part. The main difficulty, and the main fun and gain comes from mastering new design and programming techniques. Most experienced programmers I have talked with quotes times from a half year to one and a half year for becomming really comfortable with C++ and the key data abstraction and object-oriented techniques it supports. That assumes that they learn on the job and stay productive - usually by programming in a ``less adventurous'' style of C++ during that period. If one could devote full time to learning C++ one would be comfortable faster, but without actual application of the new ideas on real projects that degree of comfort could be misleading. Object-oriented programming and object-oriented design are essentially practical - rather then theoretical - disciplines. Unapplied, or applied only to toy examples, these ideas can become dangerous ``religions.''

同样的，这视情况而定，这依您的经验以及您所谓的"学习C++"是什么而定，以较好 的C风格所需的语法及基础，加上定义并使用一些简单的类别来撰写C++，这些对于一个程式设计人员来说需要花上一到两个星期的时间，这还是简单的部份，主 要的困难、乐趣及获得，来自于新设计与编程技术，我所遇过大多数有经验的程式设计人员花了半年至一年半的时间，才得以真正熟悉C++、及它所支援的关键的 资料抽象化与物件导向技术。这是假设他们仍在职且持续保有生产力 - 在这段时间通常以"较不冒险"的C++风格来写作程式。如果有人能全心付出时间来学习C++，他会更快的熟悉，但是就没有办法在实际的专桉上将新想法应用 上去，而熟悉的指数可能失去意义。物件导向编程与物件导向设计基本上是实用（而不是理论）法则，没有办法应用或只应用在一些玩具般的例子，这些想法可能变 成危险的"教条"。 

Note that learning C++ is then primarily leaning programming and design techniques, not language details. Having worked through a good textbook I would suggest a book on design such as

注意到学习C++主要是学习编程与设计技术，而不是语言的细节，在看过一本好的书本 之后，在设计上我再建议这本： 

Grady Booch: 

Object Oriented Design with examples 

Benjamin Cummings 1990. 

which has the nice property of having longish examples in five different languages (Ada, CLOS, C++, Smalltalk, and Object Pascal) and is therefore somewhat immune to the language biogotry that mar some design discussions. The parts of the book I like best is the presentation the design concepts and the example chapters.

这本不错的地方在于有五种不同的程式语言撰写（Ada、CLOS、C++、 Smalltalk与Object Pascal）的稍长范例，并且因此可以免于语言间的差异而有损于一些设计讨论，这本书我最喜欢的部份是设计观念的表现方式与范例章节。 

Looking at design contrasts sharply with the approach  of looking very carefully at the details of the definition of C++ - usually using the ARM

以细心观看C++定义细节的方式来看看设计合同 - 通常使用 ARM： 

Ellist&Stroustrup: 

The Annotated C++ Reference Manual 

Addison-Wesley, 1990 

which is a book containing much useful information, but no information about how to write C++ programs. A focus on details can be very distracting and lead to poor use of the language. You wouldn't try to learn a foreign language from a dictionary and grammar, would you?

这是一本包括相当有用资讯的书，但没有如何撰写C++程式的资讯。专注于细节会令人 困扰且导致以蹩脚的方式使用语言，您不会想尝试从字典与文法中开始学习一个外国语言吧，不是吗？ 

When learning C++, it is essential to keep the key design notions in mind so that one doesn't get lost in the language technical details. That done, learning and using C++ can be both fun and productive. A little C++ can lead to significant benefits compared to C, further efforts to understand data abstraction and object-oriented techniques yields further benefits.

在学习C++时，谨记关键的设计概念是基本的，如此您才不会迷失在语言技术的细节中，一旦这么作后，学习与使用C++就会变得有趣且具有生产力，只要一点 点的C++就会比使用C得到更多的好处，进一步努力以瞭解资料抽象化与物件导向技术会获得更进一步的效益。 

- Bjarne Stroustrup