Apart from converting the ASCII message to HTML, I have not edited it here.
I think the practical concern underlying many of these discussions is:
Given that I don't have much time to learn new techniquesand concepts, how do I start using C++ effectively?It is clear that to use C++ ``best'' in an arbitrary situation youneed a deep understanding of many concepts and techniques, but thatcan only be achieved through years of study and experiments. It islittle help to tell a novice (a novice with C++, typically not anovice with programming in general), first to gain a thoroughunderstanding 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 nextproject. All of those topics are worthy of study and would - in thelong run - help, but practical programmers (and students) cannottake years off from whatever they are doing for a comprehensivestudy of programming languages and techniques.
On the other hand, most novices understand that ``a little knowledgeis a dangerous thing'' and would like some assurance that the littlethey can afford time to learn before/while starting their next projectwill be of help and not a distraction or a hinderance to the successof that project. They would also like to be confident that the littlenew they can absorb immediately can be part of a path that can leadto the more comprehensive understanding actually desired rather thanan isolated skill leading nowhere further.
Naturally, more than one approach can fulfill these criteria andexactly 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 imporatanceof this: after all, it appears so much more cost effective - andeasier - to ``educate'' people in large batches rather thanbothering with individuals.
Consider a few common questions:
To show my inclinations:
To learn C use:
Kernighan and Ritchie:The C programming Language (2nd edition)Prentice Hall, 1988.as the primary textbook.
To learn C++ use
Stroustrup:The C++ Programming Language (2nd edition).Addison Wesley, 1991.Both books have the advantage of combining a tutorial presentationof language features and techniques with a complete reference manual.Both describes their respective languages rather than particularimplementations and neither attempts to describe particular librariesshipped with particular implementations.
There are many other good textbooks and many other styles ofpresentation, but these are my favorites for comprehensionof concepts and styles. It is always wise to look carefullyat at least two sources of information to compensate for biasand possible shortcommings.
Naturally, learning both C++ and Smalltalk so that you can draw froma wider field of experience and examples is the ideal, but peoplewho haven't taken the time to digest all the new ideas often end up``writing Smalltalk in C++'' that is applying Smalltalk design notionsthat doesn't fit well in C++. This can be as sub-optimal writing C orFortran in C++.
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 mentioningthat I think that a general purpose programming language ought toand can support more than one programming style (``paradigm'').
The point here is that styles that are appropriate and wellsupported 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 advantageof C++'s static type system rather than fights it. Smalltalksupport a dynamic type system (only) and that view translatedinto C++ leads to extensive unsafe and ugly casting.
I consider most casts in C++ programs signs of poor design. Somecasts are essential, but most aren't. In my experience, old-timeC programmers using C++ and C++ programmers introduced to OOPthrough Smalltalk are among the heaviest users of casts of thekind that could have been avoided by more careful design.
In addition, Smalltalk encourages people to see inheritance asthe sole or at least primary way of organizing programs and toorganize classes into single-rooted hierarchies. In C++, classesare types and inheritance is by no means the only means of organizingprograms. In particular, templates is the primary means forrepresenting container classes.
I am also deeply suspicious of arguments proclaiming the need to FORCEpeople to write in an object-oriented style. People who don't want tolearn can, on average, not be taught with reasonable effort and thereis in my experience no shortage of people who DO want to learn. Unlessyou manage to demonstrate the principle behind data abstraction andobject-oriented programming all you'll get is inappropriate ``barouque''misuses of the language features that support these notions - in C++,Smalltalk, or whatever.
See ``The C++ Programming (2nd Edition)'' and in particular Chapter 12for a more thorough discussion of the relation between C++ languagefeatures and design.
It is - in my opinion - dangerous to rush through the earlier stagesbecause there is too high a probability of missing some key point.
For example, an experience C programmer might consider the ``betterC'' subset of C ``well known'' and skip the 100 pages or so of atextbook that describes it. However, in doing so he might miss theability to overload functions, the difference between initializationand assignment, the use of the `new' operator for allocation, theexplanation of references, or some other minor feature in such a waythat it will come back to haunt him at a later stage where sufficientnew concepts are in play to complicate matters. If the concepts usedin the better C subset are known the 100 pages will only take a coupleof hours to learn and some details will be interesting and useful.If not, the time spent is essential.
Some people have expressed fear that this ``gradual approach'' leadspeople to write in C style forever. This is of course a possibleoutcome, but nowhere as likely as proponents of ``pure'' languagesand proponents of the use of ``force'' in teaching programming liketo believe. The key thing to realize is that using C++ well as adata abstraction and/or object-oriented language requires theunderstanding of a few new concepts that have no direct counterpartin languages such as C and 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 andmastered through practice. Old and well-tried habits of work haveto be re-evaluated, and rather than dashing of doing things ``thegood old way'' new ways have to be considered - and often doingthings a new way will be harder and more time-consuming thanthe old way - when tried for the first time.
The overwhelming experience is that taking the time and making theeffort to learn the key data abstraction and object-oriented techniquesis worth while for almost all programmers and yields benefits notjust 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 mostbenefits requires the extra effort to learn new concepts - I wouldwonder why anyone not willing to make that effort would switch to C++.
When approaching C++ for the first time, or for the first time aftersome time, take the time to read a good textbook or a few well chosenarticles (the C++ Report and the C++ Journal contain many). Maybe alsohave a look at the definition or the source code of some major libraryand consider the techniques and concepts used. This is also a good ideafor people who has used C++ for some time. Many could do with a reviewof the concepts and techniques. Much has happened to C++ and its associatedprogramming and design techniques since C++ first appeared. A quickcomparison of the 1st and the 2nd edition of ``The C++ ProgrammingLanguage'' should convince anyone of that.
Note that learning C++ is then primarily leaning programming and designtechniques, not language details. Having worked through a good textbookI would suggest a book on design such as
Grady Booch:Object Oriented Design with examplesBenjamin Cummings 1990.which has the nice property of having longish examples in five differentlanguages (Ada, CLOS, C++, Smalltalk, and Object Pascal) and is thereforesomewhat immune to the language biogotry that mar some design discussions.The parts of the book I like best is the presentation the design conceptsand the example chapters.
Looking at design contrasts sharply with the approach of looking verycarefully at the details of the definition of C++ - usually using the ARM
Ellis & Stroustrup:The Annotated C++ Reference Manual.Addison-Wesley, 1990which is a book containing much useful information, but no informationabout how to write C++ programs. A focus on details can be very distractingand lead to poor use of the language. You wouldn't try to learn a foreignlanguage from a dictionary and grammar, would you?
When learning C++, it is essential to keep the key design notions in mindso 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++ canlead to significant benefits compared to C, further efforts to understanddata abstraction and object-oriented techniques yields further benefits.