Average Customer Review: 
This book is very interesting in that it doesn't tell you how to program in C++ but rather highlights why C++ is the way it is today. It starts with the very roots, an extension to the C language ('C with classes'') Bjarne devised back in 1979, because he faced a software engineering problem at the time where all currently available tools seemed inappropriate. This highly real world oriented design attitude was kept throughout the evolution of C++ - Bjarne specifically didn't want to produce an 'academic' language. This view and the absolute necessity for C compatibility and efficiency explain lots, if not all, of C++s more ugly syntactic and semantic constructs. While the book has chapters dealing with very specific parts of the language, I found the philosophical chapters the most interesting. These explain the author's personal views on programming and design in general and consequently why certain things were accepted or rejected into C++. Bjarne stresses the point that C++ was designed from the beginning to be a 'multiple paradigm' language. Object oriented programming was never meant to be, and is not, the only valid - holy grail - style of programming, that many make it out to be. It's quite frustrating to see features devised ten years ago still not properly supported by the current crop of compilers, templates for example (export anyone?).
The book is not for the novice programmer, but for the experienced C++ user who wants to know the whys behind the language. While a novice might be interested in that information too, it is not an advisable lecture for those readers, since they might easily get confused with the source code examples showing directions in which C++ did not evolve.
To quote one of the design goals: 'C++ is a general-purpose language designed to make programming more enjoyable for the serious programmer' - I think it succeeded.
| Entry point to becoming an educated C++ programmer! | |
My C++ education started around the time when there were no real C++ compilers, a broken translator from AT&T was all there was. Seemingly unending bugs in that translator, grossly incomplete implementation, and some fellow graduate students working in the areas of programming languages gave me enough knowledge to realize the limitations of C++. And, ah, I also read Bjarne Stroustrup's occasional postings to comp.lang.c++ Internet news group, as a counterbalance to the rest of my experiences. Before I could become a "card carrying member of the C++ haters group", this book arrived. I learned to appreciate C++ inspite of it being what it is: C++ ("not even a B!").That's what this book does - explain the various decisions that have been made in the design of the languge, as it evolved at Bell Labs in the mid eighties and early nineties. Side by side, it also records the relevant history of the development of the language ("evolution"). If you are a new C++ programmer, or even one who uses C++ as an "improved C" (whatever that is supposed to mean!), then you probably won't find much to appreciate in this. On the other hand if you have struggled with the more arcane features of it, or wondered about the features from your favorite language missing in C++, this book will most likely explain the reasons behind those. By understanding why a feature is supported or not supported should help you understand the paradigm of programming in C++ and thus help you write better C++ programs. Judging from this book (and NOT from the First Edition of his book on C++ language!), Stroustrup is an outstanding writer. The book is well edited - detailed where tolerable; interesting, precise and to the point where necessary, trimmed where it could have been boring. All in all, a very readable and educating book. Sometime ago, I had to teach a course in Software Engineering to some Computer Science graduate students. I made this a "strongly suggested reading" for the course. In addtion to desisgn and evolution of C++, you also get an insight into Stroustrup's overall philosophy in Programming Languages, Computer Science, and in general about Software, thorugh interspersed opinions - which are variously funny, witty, humorous, and always insightful. ("... overloading the white space [to make F=MA semantically equivalent to F=M*A] is beyond the scope of this book ...", "... students showed their usual creativity in avoiding the paper work [to get the software] ..."!). All in all, this is a nice book that I read the first time in 1994. Since then have read it two more times so far, and frequently recommend to other competent C++ programmers. (And, in spite of Java, C#, Perl, Ruby and what not, C++ has continued to be my first language in programming!)
| Required reading before making a suggestion for C++ additons | |
This is probably the most well written B. Stroustrup book. Without dwelling too much on the arcane, Bjarne goes over all of the reasons for the additions to the "C" language to create C++. Bjarne comes off as a guy just trying to get a job done and yet do what is right for the rest of the programming community. Its a nice change from the almost religious furor discussions that occurr on USNET.There are still open issues among the users of C++, people who want a feature found in another language, or wish that their personal idea would be incorporated into the general language. Before posting a proposal to comp.std.c++ you should read this book. There you will most likely find a discussion on the idea and why it is either not implemented, or was rejected. Then you can organize your counter argument without wasting everyone's time. (Also one of the first counter posts will be a citation to this book.) It's not that C++ is the perfect language, it isn't, after all my pet idea of overloading operator.() was rejected, but in ammending the ISO99 C++ standard you need to know what has already been discussed. So we can go forward without rehashing. Intermediate C++ programmers would also benefit from the discussions on casting, use of private/public/protected inheritence and scoping, and exceptions. Bjarne goes over why these things changed over time and what problems these features are intended to solve.
|
