C In Action: Industrial-Strength Programming Techniquespicks up where the standard tutorial leaves off, providing a fresh perspective on the language for both the novice and seasoned C programmer. Focusing on programming technique, this book captures the essence of expression in C, promoting a methodology that delivers robust, reliable, and elegant code.
This project-based tutorial begins with an overview of the language, stressing "conversational C." Focusing on technique, C In Action describes how to avoid pitfalls and how to understand, modify, and debug C. This book teaches the programmer how to write small, fast, reliable, and scalable programs within a sensible timeframe. In addition, it provides extensive coverage of Windows programming in C and the development of large-scale projects with the language.
Throughout this unique and comprehensive guide, the author offers tried and tested techniques for working with C, including:
- How to make efficient use of the Standard Template Library in C
- Implementation strategies in C, including top-down object-oriented implementation
- Plusses and pitfalls of C for programmers with C or Java programming backgrounds
- Resource management andthe use of exception handling in C
- Windows programming in C, including encapsulating the Windows API into C classes, namespaces, and templates
- How to refactor your program so that it can be ported from Windows to other platforms such as Linux
- The dynamics of large software project managementfrom conception to shipment
- How to coordinate the development of a team programming environment in C
The accompanying CD-ROM contains all of the source code referenced in the book along with the Code Co-op™ serverless version control system (VCS), which will run all of the projects in this book. The companion Web site at ...
- Addison Wesley Professional
- Publication date:
- Edition description:
- Product dimensions:
- 7.40(w) x 9.23(h) x 0.96(d)
Read an Excerpt
Why This Book?
Indeed, why YABOC11 (Yet Another Book on C11)? There are already many excellent books describing all imaginable aspects of C11. As far as learning the language and all kinds of programming tricks, the market is pretty much saturated. This book is not a language reference or a collection of clever tricks and patterns. This book is about programming.
Teaching programming is very different from teaching a language. A programmer is usually faced with a problem that he or she has to solve by writing a programnot with a language feature whose use he or she wants to illustrate. In this book I try to show, as much as possible, how to use the language as a tool to solve programming problems.
I center the presentation around various software projects. In each project I first describe a problem to be solved. Then I discuss what the program should do, what it should look like, and how it should react to user input. Based on that I build a scaffolding that captures the structure of the program without implementing its functionality. Finally, I implement the functionality, component by component.
But programming doesn't stop there. Whatfollows in this book is a long series of code reviews each followed by a rewrite. "How can this be done better?" is a question a programmer asks himself or herself constantly. And then another question becomes more and more relevant, "How do I write code that can be easily revised?"
In programming, as in life, there is never a single way to do something. That's why being able to argue about various solutions is extremely important. Programmers who don't know how to argue end up bitter and frustrated. I remember my own frustrations when faced with an argument like, "Because it's always been done like this." In this book I argue a lot. I try to find the pros and cons of every solution, and in many cases I manage to settle on something I consider "elegant." However, I never use elegance as an objective criterion. I believe that one can always uncover some very practical arguments that are hidden behind the subjective impression of "elegance." An elegant solution in many cases catches a very good abstraction or generalization. It results in code that is easy to understand, modify, and debug.
Finally, in this book I emphasize the human factor in programming. My credo is "programs are written for programmers, not computers." Programmers want to write better programs not in order to make them more understandable to computers, but to make them more readable to humans. Program maintenance is impossible without program understanding. This may seem like an obvious thing to say, but many programmers overlook this self-evident truth.
Who are you, the reader of this book? You might be a relative beginner who has picked up some programming but wants to learn C11. You might be a student who wants to supplement his or her college education. You might be a well-trained programmer who is trying to make a transition from the academic to the industrial environment. Or you might be a seasoned programmer in search of new ideas. I hope this book will satisfy you no matter which category you are in.
Why should I, of all people, write a book about programming in C11? You, the potential reader of this book, have the right to ask about my credentials, especially because I'm not a computer scientist by education.
I have a Ph.D. in theoretical physicsmy thesis was about supersymmetric nonlinear sigma models. I used to be pretty good at calculating supersymmetric Feynman diagrams. Then, around 1986 I fell in love with computers, quit my postdoc position, and began programming.
A physicist is somebody who's in between a mathematician and an engineer. A physicist is used to constantly moving between theory and practice. He or she is not expected to believe in a theory unless it has proven itself in practice, and will always try to generalize every aspect of experience in order to find an underlying principle. And, most of all, a physicist is not supposed to take anything for granted.
Unlike a mathematician, a physicist has to be more realistic and care more about the process than the formal theory. The process in physics is performing calculations. In programming, it's software maintenance. So, since I'm a physicist, it should come as no surprise that this book focuses more on rewriting programs than on creating them.
I started teaching C11 and writing this book in 1994, while still working at Microsoft. I took a sabbatical to visit my alma mater, the University of Wroclaw in Poland. It turned out that I would visit that institution several more times, and each visit would prompt me to write a few more chapters. At some point I started converting the book to HTML and posting it on the web. Since C11 was still evolving, I had to rewrite many chapters over and over again. For example, when STL became part of the C11 standard library, I had to go back and rethink the implementation of most code examples in the book.
A lot of techniques described in this book were developed while I was working at Microsoft, designing and leading the development of the Index Server. After that, my new company, Reliable Software, turned out to be a great lab for testing new programming methodologies. All the techniques described in this book have been incorporated into our own products. In fact, we keep rewriting our code every time a new, better idea comes along.
Being a physicist makes me both a good programmer and a bad programmer. Good, because I constantly revise my techniques, search for new generalizations, and discuss every aspect of programming to death. Bad, because when I find a better solution I want to rewrite everything (I will try to convince you that it's actually not such a bad idea). Managers on my previous jobs always had problems with me, because I questioned every decision, convention, and custom. I hope the same qualities will make me a good writer.
If you, the reader, find a better way of doing something described in this book, please let me know, so I can start rewriting this book for the nth time. My e-mail address is firstname.lastname@example.org.
I am most grateful to my students from the University of Wroclaw and from the Digipen Institute of Technology, because the best way to learn something is to teach it. Thanks go to Professor Jerzy Lukierski, who invited me back to the university to teach computer science. I am also indebted to my coworkers at Microsoft and Reliable Software, who were the first to try and improve many techniques described in this book. My wife, Pam, besides supporting me in all my endeavors, helped me edit the first chapter of this book, making it so much easier to understand. Many thanks to editors from Addison-Wesley, especially Debbie Lafferty.
Most Helpful Customer Reviews
See all customer reviews