加载中…
个人资料
卿卿Antony
卿卿Antony
  • 博客等级:
  • 博客积分:0
  • 博客访问:22,034
  • 关注人气:21
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

C++ Gossip: C++爸爸(Bjarne Stroustrup)给C++初学者的信(B)

(2007-09-08 12:20:51)
标签:

人文/历史

计算机程序设计

 

虽然标题各不相同,但已经有过好几个与学习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.

 

 

 

 

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有