Customer Reviews


33 Reviews
5 star:
 (21)
4 star:
 (7)
3 star:
 (2)
2 star:
 (3)
1 star:    (0)
 
 
 
 
 
Average Customer Review
Share your thoughts with other customers
Create your own review
 
 

The most helpful favorable review
The most helpful critical review


51 of 51 people found the following review helpful
4.0 out of 5 stars A Must-Read, but Dated and Wordy
This book is a must-read for any serious C++ programmer. Why? Because it is the only decent treatment of physical C++ design available.
Physical design issues, if not addressed, will inexorably cripple any sufficiently complex, performance-sensitive C++ project. Moreover, there is never any time to worry about physical design quality in the heat of battle, so you...
Published on July 23, 2002 by Anders Johnson

versus
45 of 49 people found the following review helpful
2.0 out of 5 stars Seriously dated
I am extremely sad for what I am about to say, but unfortunately this book has lost most if not all of its relevance over the last 15 years. I don't think today is a very useful book to read anymore.

Context:
I read a few books on and around C++ (say the 4 Sutter's, the 2 Alexandrescu's, the 3 Meyers, many parts of Knuth's Art of Computer Programming,...
Published on February 17, 2010 by Luca Fascione


‹ Previous | 1 2 3 4 | Next ›
Most Helpful First | Newest First

51 of 51 people found the following review helpful
4.0 out of 5 stars A Must-Read, but Dated and Wordy, July 23, 2002
By 
Anders Johnson (San Jose, CA United States) - See all my reviews
(REAL NAME)   
Verified Purchase(What's this?)
This review is from: Large-Scale C++ Software Design (Paperback)
This book is a must-read for any serious C++ programmer. Why? Because it is the only decent treatment of physical C++ design available.
Physical design issues, if not addressed, will inexorably cripple any sufficiently complex, performance-sensitive C++ project. Moreover, there is never any time to worry about physical design quality in the heat of battle, so you really need to deal with it up front.
Having said that, the book is not without its flaws.
First, the age of the text is evident. It doesn't address the interchangeability of typedefs and classes for certain purposes, it doesn't fully appreciate the power of namespaces, and it is rife with "the World didn't go that way" conventions. Fortunately, this doesn't prevent the book from getting its point across, but you do need to take some of its "rules" with a grain of salt.
Second, it's longer than it needs to be. This isn't so much of a liability, because it reads faster as a result. Still, its redundancy and long-windedness is sometimes tedious.
But all in all, if you've bothered to read this review, then you probably ought to own a copy of this book.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


32 of 33 people found the following review helpful
5.0 out of 5 stars Invaluable for its unique insistence on gritty realism., March 25, 1999
This review is from: Large-Scale C++ Software Design (Paperback)
Have you ever noticed that none of your introductions to C++ ever mention things like header files? This book corrects that omission with a vengeance, taking us deep into the nuts and bolts of real software. It describes things no other book is going to mention (e.g. redundant external include guards, or static nonmember functions to replace private members) and things the object-oriented community prefers to be silent about (e.g., encapsulation in files, not in classes).
Lakos's great strength is in pragmatics; this is advice on programming from someone who has been there. If your project is large enough to need source code control, it's large enough to need this book.
Sometimes the book drifts away from its roots, assuming a dragging academic tone. However, this does not change the overall rating -- a book with no substitutes.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


45 of 49 people found the following review helpful
2.0 out of 5 stars Seriously dated, February 17, 2010
Verified Purchase(What's this?)
This review is from: Large-Scale C++ Software Design (Paperback)
I am extremely sad for what I am about to say, but unfortunately this book has lost most if not all of its relevance over the last 15 years. I don't think today is a very useful book to read anymore.

Context:
I read a few books on and around C++ (say the 4 Sutter's, the 2 Alexandrescu's, the 3 Meyers, many parts of Knuth's Art of Computer Programming, Kernighan and Pike, Refactoring, Design Patterns, Analysis Patterns) and maybe about a half of this book. A this point I stopped. Note that this is well into the physical design part, which was the reason I bought this book in the first place. I am extremely disappointed with the book, enough that this is probably the first time I don't finish a programming book.

Review:
There are two principal bad points about this book: one is the density is way too low, the book is about 600 pages, the same stuff should have been edited down to maybe 250 (one could say this is the editor's job, btw, but still it's our time which is not made best use of). The other one is that most of what the author talks about are either suggestions for protocols that nobody would use today (take the proposed iterator interface: since the STL became standard, nobody iterates like Lakos suggests anymore) or, worse, based on circumstantial evidence of the system the author was using at that time: a lot of the book is concerned with reducing inclusion dependencies which in the text is mostly supported by a measurement the author made on his system, and then marginally by the necessity of being able to undergo low costs when moving files around a project for reuse (which instead, on its own, is a pretty good point: if there's too many complex inclusion dependencies, relocating a file for refactoring, or pulling it into a different project can become a nightmare).

Unfortunately he took a seriously wrong choice to attack his problem: he chose to manually solve the problem with various tricks and hacks such as external include guards, instead of building himself a simple tool like a pre-preprocessor or something of the kind. Needless to say, for the case in point, modern compilers have no need for such guards, as single inclusion is built into all the (current) tool chains I know *OF* (let alone the ones I use!) (this is necessary for building big systems, because headers could reside on a network, and it would be unwise to pull the same file across multiple times, once you have the file across, you parse it once, and then use it as necessary). So yes, he deserves the credit for identifying a problem (assuming he's been the first to describe it), but most certainly not much credit for the solutions proposed.

While reading, I have spent copious amounts of energy trying to salvage in my mind the most from what the author suggests, but I gave up, under the impression that the update work needed was quite more than the information that could be kept unchanged.

At this point I went back, and reread all the reviews on Amazon and figured that the part I read was actually the "good" one, while the section on logic design was even more out of date, and this is where I stopped reading.

Summing up, the one good point of the book is outlining that headers can be thought of as graphs of dependencies, and that keeping these graphs as acyclic as possible solves so many problems that it's for sure well worth including as one of the primary design goals in a project. A few techniques are shown on how to achieve this goal. Some are of some value, none was particularly non-obvious (any simple technique in Sutter, Meyers or Alexandrescu is quite more sophisticated than what's discussed here).

So, any book that pointed out what I said in the phrase above is worth maybe two stars, this author lost one due to his complete inability to summarize and come directly to a point. One extra star was then added in consideration to the person who so warmly recommended this book, as he is a very experienced programmer.

By the way, I realized after the fact that I have also been (in the past) a user of one of the packages from the company the author was working for, as well as a couple of competitor and more or less equivalent packages. I most definitely cannot say that *from the user experience standpoint* the product was any better than the others, actually it seemed quite disrespectful of standard platform conventions for default file storage, for example.

One last word:
I'm not sure this is relevant to all readers, but the style and typography of this book are surprisingly poor. The text is set too big and is poorly spaced, there are too many visual jumps in spacing and density, many pictures are related to text in a non-visible page (typically the previous one) and most pictures are way too big for the little information they represent. For a book that has received this level of credit (and a publisher of otherwise rather beautiful books) I had expected a *much* better look and feel than this.

Other Resources:
I think a more modern replacement for this book would be Sutter and Alexandrescu's "C++ Coding Standards", which does not have an explicit part on physical design issues, but gives you enough food for thought to build yourself quite naturally good practices in that domain based on the rest of the discussion. One of their opening points is "don't sweat the small stuff". Great advice.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


13 of 14 people found the following review helpful
5.0 out of 5 stars Excellent book covering important but rare ropics, April 14, 2000
This review is from: Large-Scale C++ Software Design (Paperback)
After having this book reccomended to me a number of times by various people, I decided to check it out. It is an excellent primer on how to design reusable classes in C++. It discusses a number of aspects of programming we tend to ignore, like the difference between logical and physical design. Anyone who wishes to write reusable, stable software in C++ should read this book.
I have one criticism, though, and that is that I believe the book is poorly organized. Although each individual peice of information in the book is useful and well thought out, I found that I wished he would cover things in a more natural order. Often I would read something and have to go back and reconcile it with what had been said earlier in the book, which was sometimes difficult. Don't let this criticism stop you from reading, however.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


21 of 25 people found the following review helpful
4.0 out of 5 stars Industrial sized software, March 19, 2001
This review is from: Large-Scale C++ Software Design (Paperback)
The complexity of developing large scale programming projects is rarely addressed in computer science texts. I find most books are written from an academic perspective that rarely addresses what "should be done" rather than what "could be done". As a systems integration professional, I found this book to be one of the few useful books that address the difference between a single person coding effort and a large scale development project.
The book is organized in three major parts. "Part I - The Basics" covers language details, common design patterns, style conventions used in the book and the fundamental design practices to be used in every C++ project. The next two sections cover the real "meat" of the information. "Part II - Physical Design Concepts" covers components, physical heirarchy, levelization, insulation and packages. The techniques in this section are designed to improved testability, reduce compile time and improve version control/configuration management. "Part III - Logical Design Issues" addresses the marriage of solid physical design with key design/architectural issues.
The book is well written and easy to follow. Logical concepts are introduced with relevant diagrams and then made tangible with actual code. I have used this book on three projects and it has helped my technical leads in every case.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


11 of 12 people found the following review helpful
5.0 out of 5 stars The Best Computer Science Book I've Ever Read - Period, January 5, 2006
By 
Verified Purchase(What's this?)
This review is from: Large-Scale C++ Software Design (Paperback)
I read this book back in 1998. It is the foundation for my understanding of the design of object oriented software. Prior to reading this book I programmed in C++ for more than 8 years. It was apparent to me that there were gaps in my understanding of how to design medium and large scale object oriented systems. This is a huge and dense book, but as I read through it, many times a light went on in my head (those ah ha moments).

The book also gives specific details about consideration for the C++ language. C++ has changed over the years, and the examples do not use newer language features. I do not feel that this is important. The code clearly illustrates the ideas, which are not limited by the state of C++ at the time the code was written.

Regardless of the object oriented language you use to develop software this book will teach invaluable concepts that I have not found explained elsewhere.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


5 of 5 people found the following review helpful
4.0 out of 5 stars The one and only book covering physical design, April 29, 2008
By 
Paul Floyd (Grenoble France) - See all my reviews
(REAL NAME)   
This review is from: Large-Scale C++ Software Design (Paperback)
I'll start with some negative points. Due to the age of this book, much of the example code is out ot date. In particular, no bool and namespaces. This means that the advice about not polluting the global namespace, and to use structs with static members instead ought to now be advice to use namespaces. There's little on the standard library. Coverage of templates (and their potential for code bloat and link time explosion) isn't great. Another issue is the enormous improvement in computer performance since this book was written. At the time, 100MHz single core subscalar CPUs were the order of the day. Now we have 2-3GHz multicore superscalar CPUs that are of the order of 1000 times faster. What would have taken a week to build then would now take minutes.

Some of the terminology used doesn't match that which I'm used to. For instance, I would tend to use composition and aggregation where Lakos uses HasA and HoldsA. I don't agree with what he calls internal linkage - basically it is everything that is not external linkage. I'd add a third category, no linkage (e.g., macros, typedefs).

Now some more positive comments. Part II is good stuff. There is a lot of detail on why components can become dependent, and ways of breaking those dependencies. He also explains quite well the disadvantages to such insulation (generally more code and/or slower). Unfortunately, I'm not aware of any easily available tools that generate the metrics that Lakos uses. Without such tools, you either have to perform lengthy analysis (or develop your own tool), or just guess roughly the state of your own system. The end of Part II goes off the boil a bit. Packages are just bigger components, and what is true for packages is also true for components. This leads to a bit of repetition. The section on startup issues is a bit fuzzy as to whether it is a logical design issue or a physical one.

Part III is good enough, but a bit off topic I feel (again getting to logical design, whilst I think the book should have stayed more with physical design). Again, there are a few things that I don't entirely agree with. For instance, advice is given to be 'const correct' [good idea in my opinion], but to only use 'int' and to avoid unsigned types. My opinion on this is that just as you should be 'const correct', then you should also be 'sign correct'. You will have a hard time using just int in real C++ code. size_t is unsigned on all of the platforms that I know, and this is the type of sizeof, the dimension of arrays, returned by strlen and so on.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


9 of 11 people found the following review helpful
4.0 out of 5 stars Good book on Physical design of OOP, July 31, 2000
By A Customer
This review is from: Large-Scale C++ Software Design (Paperback)
Though over 800 pages, it is very easy to read book. I think the presentation is well organized. All the major points are outlined clearly. following the charts, tables,graphes and sources, one can get essence of phyicial design immediately. (sometime I feel funny about all the definitions given by Mr.Lakos, they're too trivial to occupy some space as principals.) PartII on physical design concept is very useful for guys that already read effective c++, design patterns etc, which mostly dwell on logicial design issues. It's a thrill when I read them fisrt time as other oop classics. I think the part III on logical design is a mistake. There are lots of very good books teaching us how to write functions, oragnizing interfaces. I learned very little from those 200+ pages.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


3 of 3 people found the following review helpful
4.0 out of 5 stars An excelent style guide for the experience C++ developer., August 1, 1996
By A Customer
This review is from: Large-Scale C++ Software Design (Paperback)
Large scale systems in C++ have frequently been ill-designed
and become a nightmare to maintain. This book teaches one how
to do things the correct way the first time. An excellent basis
for a corporate standard for C++ development.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


2 of 2 people found the following review helpful
5.0 out of 5 stars An excellent analysis of physical design., June 12, 2001
By 
Daniel Mall (San Gabriel, CA United States) - See all my reviews
(REAL NAME)   
This review is from: Large-Scale C++ Software Design (Paperback)
This comprehensive reference covers all aspects of physical design in C++. The material is relevant to all C++ projects however the effects of poor physical design are amplified in large-scale projects. John Lakos illustrates how to eliminate cyclical dependencies, excessive link-time dependencies, and excessive compile-tine dependencies. Provides guidance for organizing the content of header files. Covers components, physical hierarchy, levelization, encapsulation, insulation, and packages. As a bonus the author includes an excellent essay on designing a function interface specification including the following tradeoffs: operator or non-operator function, free or member operator, virtual or non-virtual function, pure or non-pure virtual member function, static or non-static member function, const or non-const member function, public, protected, or private member function, return by value, reference, or pointer, return const or non-const, friend or non-friend function, and inline or non-inline function. Includes a dependency extractor/analyzer package in appendix C.
Help other customers find the most helpful reviews 
Was this review helpful to you? Yes No


‹ Previous | 1 2 3 4 | Next ›
Most Helpful First | Newest First

Details

Large-Scale C++ Software Design
Large-Scale C++ Software Design by John S. Lakos (Paperback - July 20, 1996)
$74.99 $50.79
In Stock
Add to cart Add to wishlist
Search these reviews only
Rate and Discover Movies
Send us feedback How can we make Amazon Customer Reviews better for you? Let us know here.