Industrial Strength C++

by Mats Henricson and Erik Nyquist

Taking the point of view that good rules make good programs, this text presents proven strategies for using and programming in the C++ object-oriented language in the form of easy-to-follow lists of... This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0131209655
• ISBN13: 9780131209657
• Release Date: January 1996
• Publisher: Prentice Hall
• Length: 240 Pages
• Weight: 1.02 lbs.
• Dimensions: 0.7" x 7.0" x 9.3"

Customer Reviews

Good, but overtaken

It's well known that C++ gives you plenty of firepower for not only shooting yourself in the foot, but blowing your whole leg off. So, if C++ is your weapon of choice, let this book (or something similar) act as your range safety officer. Rules like these don't stop all bad things from happening, but they cut the inevitable coding errors and maintenance problems way down. These authors originated the Ellemtel coding guidelines, the 1992 predecessors to MISRA and lots of others. This 1996 book builds on that earlier set of rules and extends them. Many of these rules seem obvious, like not casting away "const" - I'd add volatile to that rule, as well. Others point out subleties that wouldn't normally occur to most people, like example 7.14 which shows how a const member function can modify the state of its object. Yet other rules don't go far enough, like the ones that recommend against some parts of the standard libraries. Today's list of no-nos includes strcpy and sprintf, because of the well-known malicious attacks that they enable. Of course, I find that some rules need to be taken with a grain of salt. I fully understand the hazards of ill-considered unions, for example. Still, unions can serve useful purposes. They can be helpful when dealing with hardware registers that have different meaning on read access than on write access, or when picking apart floating point numbers for emulation on integer processors. And, depending on the criticality of your application, these rules skip whole ranges of important practices, like checking for numerical overflow in basic arithmetic operations. The authors do an excellent job of stating each rule and providing motivating examples for it. So why don't I give it that fifth star? The big reason is age - later rule sets spawned by this one have overtaken it. Others rule sets, written for specific environments, address particular needs better than this one-size-fits-all guide, too. Still, if you think that style guides just talk about how many spaces to indent and where to put the capitals, you really need to think again. Despite its age, this will get you thinking in the right direction. -- wiredweird

Definitely One of the Best

The book itself has a long history from it's beginnings as a coding standard for an actual live company. Its authors were quick to convince their employers that it would be beneficial to the company and the community at large to make the document public. The rest is history. It was translated to English and then released to the community, where it was torn down and tossed around and improved. Even though there are various places where you can find this book online, it is definitely one that is worth having a physical copy of. While some of the suggestions in this book do border on stylistic guidelines, the vast majority of it is geared towards making your code readable and easy to debug. The majority of what the author considers to be strictly stylistic is included in an individual appendix at the back of the book. I will make one simple detracting comment. Some of the information is potentially outdated. The only reason I say this however, is that the book makes the assumption that some operating systems will only support 8.3 format file names. Now that Microsoft Windows has full support for long file names, and Linux has had such support for as long as most of us can remember, this will not often be the case. These warnings are still good to take into account at times however, as they will let us remember that not every system will be as we expect. Hands down, I would suggest that every C++ programmer get a copy of this book for their collection.