In a cycling road race, the first hour or so of racing is generally pretty steady, with all the riders feeling their way into the race, warming up overtrained muscles, taking on board a last few calories, planning their strategies and tactics for the coming hours, and renewing acquaintances with friends and colleagues who they may not have seen for some time.
The first part of your journey with Imperfect C++ will be in a similar vein. You'll meet several things that you already know, or at least have heard of, many of which will be important to remember in later parts of the book. The pace is measured, the tone is optimistic—we have the whole road ahead of us, after all—and there shouldn't be too many contentious bumps in the road at this point.
That's not to say that you'll not be expending energy in the reading, but things will seem calmer at least. Indeed, there're only two imperfections defined in the six chapters in this part. Of course, there'll be lots of imperfect issues covered, but the focus is more about looking at some C++ fundamentals—the ontological issues in particular—in new ways.
Because this book is unashamedly about achieving quality in the context of the real world of work, we begin by looking at mechanisms for enforcing the design decisions we make in creating our classes, both at compile time and run time. After this, we go back to basics, and look at object lifetime, and the mechanisms for controlling client access to member data. Then we get all preachy on the virtues of using member initialization lists (section 2.3).
Next comes resource encapsulation. Since we don't have enough acronyms in computing, I introduce a new one, RRID (section 3.4), which is the half-brother of RAII (Resource Acquisition Is Initialization; section 3.5), arguably the most important feature of C++, and one that sets it head and shoulders above its C-language brethren. The notion of a value type is examined, ranging from simple data structures right through to arithmetic value types, which are able to emulate the syntax of built-in operations for arbitrarily complex operations. We also look at data encapsulation, which goes swimmingly, until we look at just how difficult it can be to provide a truly encapsulated type in the real world.
There's a discussion of object access models to help clear up the terminological soup (in my head at least) concerning whether you share, copy, borrow, or take one object from another. Because C++ just does it so embarrassingly well, we end by really going to town on scoping classes. We get to see just how far we can poke this marvelously simple language feature around the cobwebbed corners of the software engineering mansion, further relieving us of work that our helpful compiler will do for us.
There are six chapters: Chapter 1, Enforcing Design: Constraints, Contracts, and Assertions; Chapter 2, Object Lifetime; Chapter 3, Resource Encapsulation; Chapter 4, Data Encapsulation and Value Types; Chapter 5, Object Access Models; and Chapter 6, Scoping Classes. If you get to the end of this part and your response is "so what?" I can live with that. It means that you long ago embraced the power of RAII and apply it absolutely everywhere that it's suitable to do so (and that's a lot of possibilities). It also means that you've adopted the principles of the Design by Contract (see Chapter 1) philosophy, and are applying them in your work. That's great, because you'll be writing robust, clear, and maintainable code.
If you're not yet in that position, I hope this part gives you some food for thought. The result is the same for you, however: rejoice in the power of RAII, apply it everywhere suitable, and spread the message; everyone's life will be made that bit easier (not to mention that it's a great comeback when the proponents of other popular languages are banging on about robustness).
