Never Say Die

Despite most of my education being in the sciences, I'm actually much more of an engineer. I loved those early sci-fi books where the heroic engineers would "jury-rig" their way out of sticky situations. That's the approach taken in this book. There's theory, and we go with that first. But as often as not, when working on the borders of the language, most of the current compilers have problems with theory, so we have to code to their reality. As Yogi Berra said, "In theory, there's no difference between theory and practice. In practice, there is."

Such an approach can bring powerful results. Engineering effort, rather than academic induction, coupled with a stubborn refusal to live with the imperfections of C++, has led me (eventually) to a number of discoveries:

• The principles of explicit generalization via Shims (Chapter 20) and the resultant phenomenon of Type Tunneling (Chapter 34)

• An expansion of C++'s type system (Chapter 18), providing discrimination between, and overloading with, conceptually separate types sharing common implementation base types

• A compiler-independent mechanism providing binary compatibility between dynamically loaded C++ objects (Chapter 8)

• An incorporation of the principles of C's powerful NULL within the rules of C++ (Chapter 15)

• A maximally "safe" and portable operator bool() (Chapter 24)

• A fine-grained breakdown of the concept of encapsulation, leading to an expanded tool kit for the efficient representation and manipulation of basic data structures (Chapters 2 and 3)

• A flexible tool for efficiently allocating dynamically sized memory blocks (Chapter 32)

• A mechanism for fast, nonintrusive string concatenation (Chapter 25)

• An appreciation for how to write code to work with different error-handling models (Chapter 19)

• A straightforward mechanism for controlling the ordering of singleton objects (Chapter 11)

• A time-and-space efficient implementation of properties for C++ (Chapter 35)

Imperfect C++ does not attempt to be the complete answer to using the C++ language. Rather it takes the developer down the path of pushing beyond the constraints that exist to finding solutions to imperfections, encouraging a new way of thinking outside of the square.

I'm not perfect; none of us are. I do bad things, and I have a heretical streak. I have a poor habit of writing protected when I should write private. I prefer to use printf() when perhaps I should be favoring the IOStreams. I like arrays and pointers, and I'm a big fan of C-compatible APIs. Nor do I adhere religiously to the hairshirt programming philosophy. But I believe that having such a philosophy, and sticking to it wherever possible, is the surest and quickest way to achieve your aims.