intro.html

Visual C++ has been one of most effective tool for the large industrial applications. This book is t

<h3>Techniques</h3>

<p>Writing good software requires much more than just learning the language. Firstly, the program doesn't execute in a vacuum. It has to interact with the computer. And interacting with the computer means going through the operating system. Without having some knowledge of the operating system, it is impossible to write serious programs. Secondly, we not only want to write programs that run--we want our programs to be small, fast, reliable, robust and scaleable. Thirdly, we want to finish the development of a program in a sensible amount of time, and we want to maintain and enhance it afterwards.
<p>The goal of the second part of the book, The <i>Techniques</i>, is to make possible the transition from 'weekend programming' to 'industrial strength programming.' 
<p>I will describe the technique that makes programming in C++ an order of magnitude more robust and maintainable. I call it "managing resources" since it is centered on the idea of a program creating, acquiring, owning and releasing various kinds of resources. For every resource, at any point in time during the execution of the program, there has to be a well-defined owner responsible for its release. This simple idea turns out to be extremely powerful in designing and maintaining complex software systems. Many a bug has been avoided or found and fixed using resource ownership analysis. 
<p>Resource management meshes very naturally with C++ exception handling. In fact, writing sensible C++ programs that use exceptions seems virtually impossible without the encapsulation of resources. So, when should you use exceptions? What do they buy you? It depends on what your response is to the following simple question: Do you always check the result of <var>new</var> (or, for C programmers, the result of <var>malloc</var>)? This is a rhetorical question. Unless you are an exceptionally careful programmer--you don't. That means you are already using exceptions, whether you want it or not. Because accessing a null pointer results in an exception called the General Protection Fault (GP-fault or Access Violation, as the programmers call it). If your program is not exception-aware, it will die a horrible death upon such an exception. What's more, the operating system will shame you by putting up a message box, leaving no doubt that it was your application that was written using sub-standard programming practices (maybe not in so many words).
<p>My point is, in order to write robust and reliable applications--and that's what this book is about--you will sooner or later have to use exceptions. Of course, there are other programming techniques that were and still are being successfully applied to the development of reasonably robust and reliable applications. None of them, however, comes close in terms of simplicity and maintainability to the application of C++ exceptions in combination with the resource management techniques.
<p>I will introduce the interaction with the operating system through a series of Windows programming exercises. They will lead the reader into new programming paradigms: message-based programming, Model-View-Controller approach to user interface, etc. 
<p>The advances in computer hardware paved the way to a new generation of PC operating systems. Preemptive multitasking and virtual memory are finally mainstream features on personal computers. So how does one write an application that takes advantage of multitasking? How does one synchronize multiple threads accessing the same data structure? And most importantly, how does multitasking mesh with the object-oriented paradigm and C++? I will try to answer these questions.
<p>Virtual memory gives your application the illusion of practically infinite memory. On a 32-bit system you can address 4 gigabytes of virtual memory--in practice the amount of available memory is limited by the size of your hard disk(s). For the application you write it means that it can easily deal with multi-megabyte memory based data structures. Or can it? Welcome to the world of thrashing! I will explain which algorithms and data structures are compatible with virtual memory and how to use memory-mapped files to save disk space.
<h3>Software Project</h3>
<p>There is more to the creation of a successful application (or system) than just learning the language and mastering the techniques. Today's commercial software projects are among the most complex engineering undertakings of humankind. Programming is essentially the art of dealing with complexity. There were many attempts to apply traditional engineering methods to control software's complexity. Modularization, software reuse, software IC's, etc. Let's face it--in general they don't work. They may be very helpful in providing low level building blocks and libraries, but they can hardly be used as guiding principles in the design and implementation of complex software projects. 
<p>The simple reason is that there is very little repetition in a piece of software. Try to visually compare a printout of a program with, say, a picture of a microprocessor wafer. You'll see a lot of repetitive patterns in the layout of the microprocessor. Piece-wise it resembles some kind of a high-tech crystal. A condensed view of a program, on the other hand, would look more like a high-tech fractal. You'd see a lot of self-similarities--large-scale patterns will resemble small-scale patterns. But you'd find very few exact matches or repetitions. Each little piece appears to be individually handcrafted. Repetitions in a program are not only unnecessary but they contribute to a maintenance nightmare. If you modify, or bug-fix, one piece of code, your are supposed to find all the copies of this piece and apply identical modifications to them as well. 
<p>This abhorrence of repetition is reflected in the production process of software. The proportion of research, design and manufacturing in the software industry is different than in other industries. Manufacturing, for instance, plays only a marginal role. Strictly speaking, electronic channels of distribution could make the manufacturing phase totally irrelevant. R & D plays a vital role, more so than in many other industries. But what really sets software development apart from others is the amount of design that goes into the product. Programming <i>is</i> designing. Designing, building prototypes, testing--over and over again. Software industry is the ultimate "design industry." 
<p>In the third part of the book I will attempt to describe the large-scale aspects of software development. I will concentrate on the dynamics of a software project, both from the point of view of management and planning as well as development strategies and tactics. I will describe the dynamics of a project from its conception to shipment. I will talk about documentation, the design process and the development process. I will not, however, try to come up with ready-made recipes because they won't work--for exactly the reasons described above. 
<p>There is a popular unflattering stereotype of a programmer as a socially challenged nerd. Somebody who would work alone at night, subsist on Twinkies, avoid direct eye contact and care very little about personal hygiene. I've known programmers like that, and I'm sure there are still some around. However most of the specimens of this old culture are becoming extinct, and for a good reason. Progress in hardware and software makes it impossible to produce any reasonably useful and reliable program while working in isolation. Teamwork is the essential part of software development.
<p>Dividing the work and coordinating the development effort of a team is always a big challenge. In traditional industries members of the team know (at least in theory) what they are doing. They learned the routine. They are performing a synchronized dance and they know the steps and hear the music. In the software industry every team member improvises the steps as he or  goes and, at the same time, composes the music for the rest of the team. 
<p>I will advocate a change of emphasis in software development. Instead of the old axiom <i>Programs are written for computers</i>. I will turn the logic upside down and claim that <i>Programs are written for programmers</i>. This statement is in fact the premise of the whole book. You can't develop industrial strength software if you don't treat you code as a publication for other programmers to read, understand and modify. You don't want your 'code' to be an exercise in cryptography.
<p>The computer is the ultimate proofing tool for your software. The compiler is your spell-checker. By running your program you attempt to test the correctness of your publication. But it's only another human being--a fellow programmer--that can understand the meaning of your program. And it is crucial that he do it with minimum effort, because without understanding, it is impossible to maintain your software.

<!-- End Main Table -->
</body>
</tr>
</table>
</html>