📄 00000001.htm
字号:
of C++'s static type system rather than fights it. Smalltalk <BR>support a dynamic type system (only) and that view translated <BR>into C++ leads to extensive unsafe and ugly casting. <BR> <BR>I consider most casts in C++ programs signs of poor design. Some <BR>casts are essential, but most aren't. In my experience, old-time <BR>C programmers using C++ and C++ programmers introduced to OOP <BR>through Smalltalk are among the heaviest users of casts of the <BR>kind that could have been avoided by more careful design. <BR> <BR>In addition, Smalltalk encourages people to see inheritance as <BR>the sole or at least primary way of organizing programs and to <BR>organize classes into single-rooted hierarchies. In C++, classes <BR>are types and inheritance is by no means the only means of organizing <BR>programs. In particular, templates is the primary means for <BR>representing container classes. <BR> <BR>I am also deeply suspicious of arguments proclaiming the need to FORCE <BR>people to write in an object-oriented style. People who don't want to <BR>learn can, on average, not be taught with reasonable effort and there <BR>is in my experience no shortage of people who DO want to learn. Unless <BR>you manage to demonstrate the principle behind data abstraction and <BR>object-oriented programming all you'll get is inappropriate ``barouque'' <BR>misuses of the language features that support these notions - in C++, <BR>Smalltalk, or whatever. <BR> <BR>See ``The C++ Programming (2nd Edition)'' and in particular Chapter 12 <BR>for a more thorough discussion of the relation between C++ language <BR>features and design. <BR> <BR> <BR> <BR>Should I start using C++ as an OOPL or as a better C? <BR> <BR>That depends. Why do you want to start using C++? The answer to that <BR>question ought to determine the way you approach C++; not some <BR>one-size-fits-all philosophy. In my experience the safest bet is <BR>to learn C++ ``bottom up,'' that is first learn the features C++ <BR>provides for traditional procedural programming, the ``better C'' <BR>sub-set, then learn to use and appreciate the data abstraction features, <BR>and then learn to use class hierarchies to organize sets of related <BR>classes. <BR> <BR>It is - in my opinion - dangerous to rush through the earlier stages <BR>because there is too high a probability of missing some key point. <BR> <BR>For example, an experience C programmer might consider the ``better <BR>C'' subset of C ``well known'' and skip the 100 pages or so of a <BR>textbook that describes it. However, in doing so he might miss the <BR>ability to overload functions, the difference between initialization <BR>and assignment, the use of the `new' operator for allocation, the <BR>explanation of references, or some other minor feature in such a way <BR>that it will come back to haunt him at a later stage where sufficient <BR>new concepts are in play to complicate matters. If the concepts used <BR>in the better C subset are known the 100 pages will only take a couple <BR>of hours to learn and some details will be interesting and useful. <BR>If not, the time spent is essential. <BR> <BR>Some people have expressed fear that this ``gradual approach'' leads <BR>people to write in C style forever. This is of course a possible <BR>outcome, but nowhere as likely as proponents of ``pure'' languages <BR>and proponents of the use of ``force'' in teaching programming like <BR>to believe. The key thing to realize is that using C++ well as a <BR>data abstraction and/or object-oriented language requires the <BR>understanding of a few new concepts that have no direct counterpart <BR>in languages such as C and Pascal. <BR> <BR>C++ isn't just a new syntax for expressing the same old ideas - <BR>at least not for most programmers. This implies a need for education, <BR>rather than mere training. New concepts have to be learned and <BR>mastered through practice. Old and well-tried habits of work have <BR>to be re-evaluated, and rather than dashing of doing things ``the <BR>good old way'' new ways have to be considered - and often doing <BR>things a new way will be harder and more time-consuming than <BR>the old way - when tried for the first time. <BR> <BR>The overwhelming experience is that taking the time and making the <BR>effort to learn the key data abstraction and object-oriented techniques <BR>is worth while for almost all programmers and yields benefits not <BR>just in the very long run but also on a three to twelve month timescale. <BR>There are benefits in using C++ without making this effort, but most <BR>benefits requires the extra effort to learn new concepts - I would <BR>wonder why anyone not willing to make that effort would switch to C++. <BR> <BR>When approaching C++ for the first time, or for the first time after <BR>some time, take the time to read a good textbook or a few well chosen <BR>articles (the C++ Report and the C++ Journal contain many). Maybe also <BR>have a look at the definition or the source code of some major library <BR>and consider the techniques and concepts used. This is also a good idea <BR>for people who has used C++ for some time. Many could do with a review <BR>of the concepts and techniques. Much has happened to C++ and its associated <BR>programming and design techniques since C++ first appeared. A quick <BR>comparison of the 1st and the 2nd edition of ``The C++ Programming <BR>Language'' should convince anyone of that. <BR> <BR> <BR> <BR>How long does it take to learn C++? <BR> <BR>Again, that depends. It depends both on your experience and on what <BR>you mean by ``learning C++.'' The syntax and basics for writing C++ <BR>in the better C style plus defining and using a few simple classes <BR>takes a week or two for a programmer. That's the easy part. The main <BR>difficulty, and the main fun and gain comes from mastering new design <BR>and programming techniques. Most experienced programmers I have talked <BR>with quotes times from a half year to one and a half year for becomming <BR>really comfortable with C++ and the key data abstraction and object- <BR>oriented techniques it supports. That assumes that they learn on the <BR>job and stay productive - usually by programming in a ``less adventurous'' <BR>style of C++ during that period. If one could devote full time to <BR>learning C++ one would be comfortable faster, but without actual <BR>application of the new ideas on real projects that degree of comfort <BR>could be misleading. Object-oriented programming and object-oriented <BR>design are essentially practical - rather then theoretical - disciplines. <BR>Unapplied, or applied only to toy examples, these ideas can become <BR>dangerous ``religions.'' <BR> <BR>Note that learning C++ is then primarily leaning programming and design <BR>techniques, not language details. Having worked through a good textbook <BR>I would suggest a book on design such as <BR> <BR>Grady Booch: <BR>Object Oriented Design with examples <BR>Benjamin Cummings 1990. <BR> <BR>which has the nice property of having longish examples in five different <BR>languages (Ada, CLOS, C++, Smalltalk, and Object Pascal) and is therefore <BR>somewhat immune to the language biogotry that mar some design discussions. <BR>The parts of the book I like best is the presentation the design concepts <BR>and the example chapters. <BR> <BR>Looking at design contrasts sharply with the approach of looking very <BR>carefully at the details of the definition of C++ - usually using the ARM <BR> <BR>Ellist&Stroustrup: <BR>The Annotated C++ Reference Manual <BR>Addison-Wesley, 1990 <BR> <BR>which is a book containing much useful information, but no information <BR>about how to write C++ programs. A focus on details can be very distracting <BR>and lead to poor use of the language. You wouldn't try to learn a foreign <BR>language from a dictionary and grammar, would you? <BR> <BR>When learning C++, it is essential to keep the key design notions in mind <BR>so that one doesn't get lost in the language technical details. That done, <BR>learning and using C++ can be both fun and productive. A little C++ can <BR>lead to significant benefits compared to C, further efforts to understand <BR>data abstraction and object-oriented techniques yields further benefits. <BR> <BR>- Bjarne Stroustrup <BR> <BR><CENTER><H1>BBS水木清华站∶精华区</H1></CENTER></BODY></HTML>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -