Large-Scale C++, Volume I

Author: John Lakos
Publisher: Addison-Wesley
Pages: 988
ISBN: 978-0201717068
Print: 0201717069
Kindle: B0826523GZ
Audience: Programmers with plenty of time to spare
Rating: 3
Reviewer Mike James:
Large Scale C++, what can this mean?

Well it certainly means a large scale book - at over 900 pages I got wrist problems trying to read it. I also have to admit that I didn't read all of it and I doubt many readers will read it cover to cover. I have to also admit that after starting to read it I was struck by a feeling that programming cannot be as difficult as this book suggests. Who, with a reasonable human brain, can possibly absorb this amount of stuff? In a good logical system what you need are a few general rules that you can apply, not 900 pages of detailed tiny design rules - hundreds of them...

This is a book of spells and, while most of them are founded in good sense, they fail to make a coherent whole. If good programmers are supposed to memorize, or even attempt to understand. this much detail then they aren't going to have much left over for anything else.

What is also important is to know that these rules are not general in the sense that they are about design in a language free context. They are about C++ and some of its strange gotchas. Some architecture books make you feel better about your language of choice. This one started to make me think that C++ was not a language any sane programmer would choose. In this I now share the opinion of Linus Torvalds:

“C++ is a terrible language”.

Banner

The first chapter digs into compilers and linkers and is much easier to understand if you already have a clear idea of what they do and what the compromises are. Some of the examples are fun, but most are obvious as soon as you think about what is going on - declarations and definitions not being resolved until link time. My feeling was "so what, as long as the problem is spotted at some point and there's no harm done" and my second feeling was that most of things listed should happen automatically if the project is reasonably well documented.

The second chapter mixes ideas of packaging with design rules. It gets into some very tiny fiddly details, like when you should use underscores in names and when camel case. Personally I don't think any of these idea solve the naming problem. There are a lot of diagrams of supposedly huge program structures - if you have a program this big its probably far too late to go back and make things simple.

Chapter 3 brings the book to a close - yes, just three chapters. It is about physical design and refactoring and it basically comes down to avoid cyclic dependencies and use lateral structures rather than layered.

Conclusion:

There were large tracts of this book I found interesting, but I have to admit that I kept trying to see a bigger picture and one didn't seem to be forthcoming. It was either very much micro-managing things or switching to huge overviews that were difficult to pin down. This isn't so much a philosophy of architecture as a rule book with justifications. It was also repetitive of basic principles - yes cyclic dependencies are bad. If the book was about 200 pages then perhaps it would work better As it is there is volume II and III to contemplate.

 

 

To keep up with our coverage of books for programmers, follow @bookwatchiprog on Twitter or subscribe to I Programmer's Books RSS feed for each day's new addition to Book Watch and for new reviews.

Banner


Understanding Software Dynamics (Addison-Wesley)

Author: Richard L. Sites
Publisher: Addison-Wesley
Pages: 464
ISBN: 978-0137589739
Print: 0137589735
Kindle: B09H5JB5HC
Audience: Every developers
Rating: 5
Reviewer: Kay Ewbank

This book looks at the different reasons why software runs too slowly, and what developers can do about it, starting by looki [ ... ]



Classic Computer Science Problems in Java

Author: David Kopec
Publisher: Manning
Date: January 2021
Pages: 264
ISBN: 978-1617297601
Print: 1617297607
Audience: Java developers
Rating: 4
Reviewer: Mike James
Getting someone else to do the hard work of converting classic problems to code seems like a good idea. It all depends which problems [ ... ]


More Reviews

Last Updated ( Tuesday, 04 May 2021 )