cppfatherletter.html

关于 C++ 的历史无须我来介绍了

<br>
To learn C++ use:<br>
<br style="font-weight: bold;">
<span style="font-weight: bold;">要学C++的话用这本：</span><br
 style="font-weight: bold;">
<span style="font-weight: bold;">Stroustrup: </span><br
 style="font-weight: bold;">
<span style="font-weight: bold;">The C++ programming Language (2nd
edition) </span><br style="font-weight: bold;">
<span style="font-weight: bold;">Addison Wesley, 1991. </span><br>
<br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br style="font-weight: bold;">
<span style="font-weight: bold;">这两本都结合了程式语言教学与技术参考手册的优点，它们说明了各自的语言而不是特定
的实作，而且并没有试图叙述一些使用在特殊用途上的特定函式库。 </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br>
还有许多其它不错的教科书与呈现方式，但对于在观念与风格上的通盘了解来看的话，这些是我的最爱。详细的看过两个以上的资讯来源总是明智的，以在一些可能
的缺点上或偏颇上能够互补。<br>
<br>
<div style="text-align: justify;">I want to do OOP, should I learn
Smalltalk before C++?<br>
</div>
<br>
<span style="font-weight: bold;">我要作OOP，要在学C++之前先学Smalltalk吗？ </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br>
<span style="font-weight: bold;">不！如果您想要学C++，就学C++。像C++、Smalltalk、
Simula、CLOS、Eiffel等的程式语言，对于抽象、继承等上，每一个都有各自的观点，而这些程式语言在支援不同特性的设计上都会有一些差异，
学习Smalltalk当然会得到不少宝贵的课程，但是它并不会告诉您如何使用C++撰写程式，事实上，除非您有时间学习与探索Smalltalk与C+
+的观念与技术，利用Smalltalk作为学习工具，在C++的设计上并没有太大的帮助。 </span><br>
<br>
<div style="text-align: justify;">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++.<br>
</div>
<br>
<span style="font-weight: bold;">当然，C++与Smalltalk两个都学，您可以从更广的领域中得到更多的经验与
实证，这是最理想的，但是人们在还没有时间消化所有的新想法时，最后通常会变成"在C++中写Smalltalk"，也就是说将Smalltalk设计中
一些不是很符合C++特性的部份加以套用，这就如同在C++中写C或者是Fortran一样的不理想。</span><br>
<br>
<div style="text-align: justify;">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'').<br>
</div>
<br>
<span style="font-weight: bold;">常见到的学习Smalltalk的理由是，它很"纯綷"，并且可以迫使人们以物件导
向的方式思考与设计程式。我不想讨论"纯綷"而不提到：我认为一个通用型的程式语言，应该且能支援一种以上的程式设计风格（模式）。 </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br>
<span style="font-weight: bold;">这边的观点在于，Smalltalk支援的一些不错的风格，在C++中不一定适合，
在C++中毫无创意的遵从Smalltalk的风格，将会导致没有效率、不良，并使得C++程式难以维护，原因在于好的C++要利用到C++静态型别系统
的设计，而不是抗拒它。Smalltalk（只）支援动态型别系统，而这些观点转移至C++将会导致广泛的安全性问题与丑陋的型态转换。 </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br>
<span style="font-weight: bold;">我认为在C++程式中大部份的型态转换都是不良设计的表现，有一些转型是必要的，但
大部份并不是如此，以我的经验中得知，一些以前使用C的C++程式设计人员，以及从Smalltalk进入OOP世界的人，都是这种型态转换的使用者，而
他们是可以透过更细心的设计来避免（这些不良设计）的。 </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br>
<div style="text-align: left;"><span style="font-weight: bold;">除此之外，
Smalltalk鼓励人们将继承视作是组织程式的灵魂，或至少是主要的方法，且将类别组织为单根的体系。在C++中，类别是型别，而继承无论如何都不可
能是组织程式的唯一方法，特别的是，范本是展现容器类别的主要方法。 </span><br>
</div>
<br>
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.<br>
<br>
<span style="font-weight: bold;">我也相当的怀疑那些宣称人们必须以物件导向风格撰写程式的论调。对于不想学习的人要
教导其付出必要的努力是没办法的，而就我的经验来说，这种不想学习的人不少。除非您想强调在资料抽象化与物件导向程式设计背后的规则，否则您只会将C+
+、Smalltalk，或其它支援这些概念的语言特性，作不适当的"巴洛克式"误用。</span><br>
<br>
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.<br>
<br>
<span style="font-weight: bold;">看看"The C++ Programming (2nd
Edition)"，尤其是在第12章有关于C++特性及设计的更多讨论。</span><br>
<br>
Should I start using C++ as an OOPL or as a better C?<br>
<br style="font-weight: bold;">
<span style="font-weight: bold;">在开始使用C++时，我要将之当作OOPL？还是"更好的C"？ </span><br>
<br>
<div style="text-align: justify;">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.<br>
</div>
<br style="font-weight: bold;">
<span style="font-weight: bold;">得看情况，为什么您要开始用C++呢？问题的答案可以决定您如何使用C++，这不是
可以全部套用的哲学。以我的经验来说，最安全的押注方式是"由下往上"学习C++，也就是说先学习C++在传统程序设计上所提供的特性 -
"较好的C"子集，然后学习使用与理解资料抽象化的特性，并且学习使用类别体系以组织相关的类别集合。 </span><br>
<br>
It is - in my opinion - dangerous to rush through the earlier stages
because there is too high a probability of missing some key point.<br>
<br>
<span style="font-weight: bold;">以我的观点来说，急急忙忙略过初阶部份相当的危险，因为很有可能忽略关键的部份。</span>
<br>
<br>
<div style="text-align: justify;">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