C++ In Action - Industrial Strength Programming Techniques

Peter Kitson

ISBN : 0201699486

Order a printed copy of this book from Amazon.

Cover Design - C++ In Action - Industrial Strength Programming Techniques

For your free electronic copy of this book please verify the numbers below. 

(We need to do this to make sure you're a person and not a malicious script)



Sample Chapter From C++ In Action - Industrial Strength Programming Techniques
     Copyright © Bartosz Milewski


The first part teaches C++, the language of choice for general-purpose programming. But it is not your usual C++ tutorial.

For the beginner who doesn't know much about C or C++, it just introduces a new object oriented language. It doesn't concentrate on syntax or grammar; it shows how to express certain ideas in C++. It is like teaching a foreign language by conversation rather than by memorizing words and grammatical rules (when I was teaching it to students, I called this part of the course "Conversational C++"). After all, this is what the programmer needs: to be able to express ideas in the form of a program written in a particular language. When I learn a foreign language, the first thing I want to know is how to say, "How much does it cost?" I don't need to learn the whole conjugation of the verb 'to cost' in the past, present and future tenses. I just want to be able to walk into a store in a foreign country and buy something.

For a C programmer who doesn't know much about C++ (other than that it's slow and cryptic--the popular myths in the C subculture) this is an exercise in unlearning C in order to effectively program in C++. Why should a C programmer unlearn C? Isn't C++ a superset of C? Unfortunately yes! The decision to make C++ compatible with C was a purely practical, marketing decision. And it worked! Instead of being a completely new product that would take decades to gain the market, it became "version 3.1" of C. This is both good and bad. It's good because backward C compatibility allowed C++, and some elements of object oriented programming, to quickly gain foothold in the programming community. It's bad because it doesn't require anybody to change his programming methodology.

Instead of having to rewrite the existing code all at once, many companies were, and still are, able to gradually phase C++ in. The usual path for such a phase-in is to introduce C++ as a 'stricter' C. In principle all C code could be recompiled as C++ . In practice, C++ has somewhat stricter type checking and the compiler is able to detect more bugs and issue more warnings. So recompiling C code using a C++ compiler is a way of cleaning up the existing code. The changes that have to be introduced into the source code at that stage are mostly bug fixes and stricter type enforcement. If the code was written in pre-ANSI C, the prototypes of all functions have to be generated. It is surprising how many bugs are detected during this ANSI-zation procedure. All this work is definitely worth the effort. A C compiler should only be used when a good C++ compiler is not available (really, a rare occurrence nowadays).

Once the C++ compiler becomes part of the programming environment, programmers sooner or later start learning new tricks and eventually they develop some kind of C++ programming methodology, either on their own or by reading various self-help books. This is where the bad news starts. There is a subset of C++ (I call it the C ghetto) where many ex-C-programmers live. A lot of C programmers start hating C++ after a glimpse of the C ghetto. They don't realize that C++ has as many good uses as misuses.

For a C-ghetto programmer this book should be a shock (I hope!). It essentially says, "whatever you did up to now was wrong" and "Kernighan and Ritchie are not gods". (Kernighan and Ritchie are the creators of C and the authors of the influential book The C Programming Language). I want to make this clear right here and now, in the introduction. I understand that the first, quite natural, reaction of such a programmer is to close the book immediately (or, actually, jump to another Internet site) and ask for a refund. Please don't do this! The shocking, iconoclastic value of this book is not there to hurt anybody's feelings. Seeing that there exists a drastically different philosophy is supposed to prompt one to rethink one's beliefs. Besides, the Emperor is naked.

For a C++ programmer, the tutorial offers a new look at the language. It shows how to avoid the pitfalls of C++ and use the language according to the way it should have been designed in the first place. I would lie if I said that C++ is a beautiful programming language. However, it is going to be, at least for some time, the most popular language for writing serious software. We may as well try to take advantage of its expressive power to write better software, rather than use it to find so many more ways to hurt ourselves. For a C++ programmer, this part of the book should be mostly easy reading. And, although the constructs and the techniques introduced there are widely known, I tried to show them from a different perspective. My overriding philosophy was to create a system that promotes maintainable, human-readable coding style. That's why I took every opportunity not only to show various programming options but also to explain why I considered some of them superior to others.

Finally, for a Java programmer, this book should be an eye-opener. It shows that, with some discipline, it is possible to write safe and robust code in C++. Everything Java can do, C++ can do, too. Plus, it can deliver unmatched performance.

But performance is not the only reason to stick with C++. The kind of elegant resource management that can be implemented in C++ is quite impossible in Java, because of Java's reliance on garbage collection. In C++ you can have objects whose lifetime is precisely defined by the scope they live in. You are guaranteed that these objects will be destroyed upon the exit from that scope. That's why you can entrust such objects with vital resources, like semaphores, file handles, database transactions, etc. Java objects, on the other hand, have undefined life spans--they are deallocated only when the runtime decides to collect them. So the way you deal with resources in Java harks back to the old C exception paradigm, where the finally clause had to do all the painfully explicit garbage collection.

There are no "native" speakers of C++. When "speaking" C++, we all have some accent that reveals our programming background. Some of us have a strong C accent, some use Smalltalk-like expressions, others Lisp--The goal of the tutorial is to come as close as possible to being a native speaker of C++. Language is a tool for expressing ideas. Therefore the emphasis is not on syntax and grammar but on the ways to express yourself. It is not "Here's a cute C++ construct and this is how you might use it." Instead it is more of "Here's an idea. How do I express it in C++?" Initially the 'ideas' take the form of simple sentences like "A star is a celestial body," or "A stack allows you to push and pop." Later the sentences are combined to form 'paragraphs.' describing the functionality of a software component. The various constructs of C++ are introduced as the need arises, always in the context of a problem that needs to be solved.