作者：Ian Joyner
副书名：A Critique of C++ and Programming and Language Trends of the 1990s
出版日期：1996
出版社：其它
页数：63
文件格式：PDF

1. Introduction
This is now the third edition of this critique; it has been four yearssince the last edition. The main factor to precipitate a new edition isthat there are now more environments and languages available thatrectify the problems of C++. The last edition was addressed to peoplewho were considering adopting C++, in particular managers who wouldhave to fund projects. There are now more choices, so comparison to thealternatives makes the critique less hypothetical.
The critique was not meant as an academic treatise, although some ofthe aspects relating to inheritance, etc., required a bit of technicalknowledge. The critique is long; it would be good if it were shorter,but that would be possible only if there were less flaws in C++. Evenso, the critique is not exhaustive of the flaws: I find new traps allthe time. Instead of documenting every trap, the critique attempts toarrange the traps into categories and principles. This is because thetraps are not just one off things, but more deeply rooted in theprinciples
of C++. Neither is the critique a repository of ‘guess what this obscure code does’ examples.
One desired outcome of this critique is that it should awaken theindustry about the C++ myth and the fact that there are now viablealternatives to C++ that do not suffer from as many technical problems.The industry needs less hype and more sensible programming practices.No language can be perfect in every situation, and tradeoffs aresometimes necessary, but you can now feel freer to choose a languagewhich is more closely suited to your needs. The alternatives to C++provide no silver bullet, but significantly reduce the risks and costsof software development compared to C++. The alternatives do not sufferunder the complexities of C++ and do not burden the programmer withmany trivialities which the compiler should handle; and they avoid manyof the flaws and inanities of C/C++.
The language events which have made an update desirable are theintroduction of Java, the wider availability of more stable versions ofEiffel, and the finalisation of the Ada 95 standard. Java in particularset out to correct the flaws of C++, and most sections in the originalcritique now make some comment on how Java addresses the problems.Eiffel never did have the same flaws as C++, and has been around sincelong before the original critique. Eiffel was designed to beobject-oriented from the ground up, rather than a bolt-on. Java offersbetter integration with OO than C++. Now that there are languagecomparisons in the critique the arguments are less hypothetical, andthe criticisms of C++ are more concrete.
Another factor has been the publishing of Bjarne Stroustrup’s “Design and Evolution of C++”
. This has many explanations of the problems of extending C with object-oriented
extensions while retaining compatibility with C. In many ways,Stroustrup reinforces comments that I made in the original critique,but I differ from Stroustrup in that I do not view the flaws of C++ asacceptable, even if they are widely known, and many programmers knowhow to avoid the traps. Programming is a complex endeavour: complex andflawed languages do not help.
A question which has been on my mind in the last few years is when is OO applicable? OO is a
universal paradigm. It is very general and powerful. There is nothingthat you could not program in it. But is this always appropriate? Lowerlevel programmers have tended to keep writing such
things as device drivers in C. It is not lower levels that I aminterested in, but the higher levels. OO might still be too low levelfor a number of applications. A recent book suggests thatsoftware engineers are too busy designing systems in terms of stacks,lists, queues, etc., instead of adopting higher level, domain-orientedarchitectures. offers some hope to the industry that we arelearning how to architect to solve problems, rather than distortingproblems to fit particular technologies and solutions.