Congratulations! You have made it through three weeks of intense, advanced C++, and now are ready to take on professional-level assignments.
Today you will learn
Before you learn about putting the final touches on your software, you will learn about version control in this section. As you develop your software, you may find that you have taken a wrong turn and need to back up. If you have been working on the only copy of your program, you easily could put yourself in a position where it takes you days to recover.
At an absolute minimum, you will want to make daily backups of your code, but that often isn't enough to get you back in business. If you changed some classes on Monday, and others on Tuesday, putting together a working version from your backups can be murderously difficult.
Version control software, also called revision control software, solves this problem and other issues as well.
In a good version control system, every file is checked into the system, and the first iteration of the file is given revision 1. When you want to revise the file, you check it out of the revision control system (RCS), edit it, and check it back in with a new revision number (myFile.cpp Rev 2, for example).
Files that are checked into the system are made read only on your local disk, so that you cannot inadvertently edit the files without checking them out again.
From time to time, you will want to create a named revision of your program (ROBIN v3, for example). You tell the RCS which version of each file to include in that name. ROBIN v3, for example, might include the following: String.cpp,5 (String.cpp revision number 5); String.hpp,4; Page,7; and so on.
Note that not all the revision numbers are the same. It is perfectly reasonable to revise one file many times between revisions while another file remains unchanged. The complete set of files for ROBIN v3 might look like this:
String.hpp, 2
String.cpp, 4
Page.cpp, 5
Page.hpp, 5
IdxMgr.cpp, 9
IdxMgr.hpp, 4
...and so on. If you make a wrong turn at some point, you always can check out of your RCS the entire set of ROBIN 3, and know that that complete set of files will create a buildable version of the program.
Once you have two or more programmers working on a product, revision control becomes an absolute necessity. It is impossible to keep track of who has a particular file without the capability to check files in and out.
If you didn't have this capability, here's what might happen. You open Idxmgr.cpp to make some revisions. At the same time, unknown to you, your partner starts making revisions to the same file. You save your changes, he saves his and overwrites yours, and all your work is lost.
You could solve this problem by never editing files that are shared on a network. You could decide, by convention, to copy those files to your local hard disk to edit them. The problem, of course, is that the overwriting just as easily could happen when the files are returned to the network.
Some developers solve this dilemma by moving the file to their local hard drive, not leaving a copy behind on the network. This solves the overwriting problem, but what if you both need to work on the file at the same time?
A good RCS will allow simultaneous edits, by letting one developer work on the trunk of the project, while the other works on a branch.
A branch is simply a revision against a file that already is checked out by another developer. If you check out ROBIN.CPP version 4, and I also want to make edits to version 4, for example, I can take out a branch. Your file will be named ROBIN,5 when you return it to the RCS, but mine will be called ROBIN,4a1.
My file will not overwrite your changes; it will stand on its own as a separate departure point from version 4. At some point, probably fairly quickly after we're both done, we will want to merge the changes back into yet another version, for example, ROBIN,6. A good RCS makes that merger easy, often providing a script or side-by-side windows for comparing and merging the two versions.
With a large and complex project, you often will find that you need to be working on bug fixes for one released version of your program even as you are developing the next released version of the program. A powerful RCS lets you accomplish this by creating an entire branch release, consisting of branched versions of every file in the project.
You therefore can work on the branch to release 2 while continuing development on release 3. Because the entire set of files has a name, it is easy to check out all the files for the latest fixes to ROBIN v2, make your edits, check the name in, and then return to working on files for ROBIN v3.
Professional level version control systems enable you to create dynamic names. You might create a name called ROBIN Latest, for example. Checking out the files in ROBIN Latest does not provide a static set of files (as checking out ROBIN v2 does) but instead provides the latest revision of every file in the ROBIN project. This feature can be enormously convenient, because most of the time you really do want the very latest version of everything.
A good product never really is finished. If you designed for extensibility and maintainability, your customers will tell you what features they would like to see added and for which features they would be willing to pay more.
The greatest single danger to V1 of your product is creeping featurism--that inevitable trend to put in just one more "essential" feature. The later your product is to market, the more market share you lose; yet, perversely, this very lateness leads some developers to feel they must add features to keep up with the competition.
I believe that you should release version 1 with the absolute minimum set of features. Early on in your development cycle, ask yourself, "What is the smallest set of features with which I can reasonably go to market?" Then cut that list!
During the development of V1, set a very high barrier to adding features, and consider eliminating those features that turn out to be expensive (in time, resources, or program size) to develop. Keep a version 2 list so that you don't forget all the cool stuff you left out of V1, but make your highest priority for V1 to get out there into the marketplace and compete.
It is my experience that far more products fail in the marketplace because of being late to market than because of being light on features. In fact, I'll go further and say that even relatively buggy code often succeeds if it is first in the market and the upgrade and bug fix are quickly available.
That latter point is dangerous, however. Many products never recover from the poor first impression they make on the market. What's more, there will be plenty of bugs left in your code if you do all you can to squash them; a tolerance of releasing buggy code is almost certain to sink you as you earn a reputation for shoddy work.
The bottom line is this: Draw up a list of the absolutely required features; develop a solid, reliable, and extensible product; and then get out there with it and start listening to your customers. They will be sure to tell you what you got wrong, and what you left out, if you listen. If you then respond and your program is seen to be good and getting better, you almost cannot help succeeding.
Commercial, shrink-wrapped, on-the-shelf, at your local software discount store programs are not the only options available to software developers now. Shareware is a huge market presence in this industry.
In short, a shareware program is free to try, but the user is obliged to purchase it if he uses it past an initial trial time. The interesting thing about shareware is that it typically is delivered via electronic online services such as Interchange, ZiffNet, and so on; or on local bulletin board systems. This accessibility means that hundreds of thousands of people will have instant access to your software.
If you are interested in this unique distribution channel, be sure to contact the Shareware Products Association for information on their guidelines for producing, marketing, distributing, and being paid for your program.
Whether you distribute your program as shareware or as a shrink-wrapped product, your customers will expect more from a product for which they are paying. At a minimum, they will expect your program to do what it says it will, to be reasonably well documented, to be reliable and robust, and, if it is both expensive and complex to be supported.
Support is a very expensive problem for the industry. Some companies have developed a very good reputation for providing excellent (and often free) telephone support. Other companies have aggravated their users with long waits to talk to misinformed and unfriendly support technicians.
Some companies still provide free, unlimited support via toll-free numbers, but in the past few years many have found this to be prohibitively expensive. Some of the larger companies have started charging for support, and many others have shunted some or all of their support to electronic services such as Interchange or CompuServe, or via fax or other indirect methods.
If your product is a simple utility, offered for free or at little expense, few will expect you to provide much support. (But don't be surprised by the occasional midnight call from an irate customer screaming, "Your program says press any key, but I don't have an AnyKey!")
The first thing you should do when you finish this book is to tap into a C++ conference on an online service. These groups supply immediate contact with hundreds or thousands of C++ programmers who can answer your questions, offer advice, and provide a sounding board for your ideas. As an advanced C++ programmer, you also can contribute to this community of ideas, which answers questions and provides advice to those just starting out.
I participate in the C++ discussions on Interchange (of course), as well as many C++ forums on Ziffnet, CompuServe, and other dial-in services. I'm also active in the C++ Internet news group (comp.lang.c++), and I recommend all of these as good sources of information and support.
Also, you might want to look for local user groups. Many cities have C++ interest groups where you can meet other programmers and exchange ideas.
The very next book I would run out and buy and read is
Meyers, Scott. Effective C++ (ISBN: 0-201-56364-9). Addison-Wesley Publishing, 1993.
This is by far the most useful book I've ever read, and I've read it three times.
At this point, however, you have a solid grounding in C++: both the syntax of the language and its more advanced capabilities. There are two obvious areas to explore from here: advanced object-oriented analysis and design; and development in a graphical user interface environment such as Windows, the Mac, or OS/2.
If you are serious about object-oriented programming and design, be sure to pick up an advanced book. Either of the following books will be a valuable addition to your library:
Booch, Grady. Object-Oriented Analysis and Design with Applications, 2nd Edition
(ISBN: 0-8053-5340-2). The Benjamin/Cummings Publishing Company, Inc., 1994.
Rumbaugh, et al. Object-Oriented Modeling and Design (ISBN: 0-13-629841-9).
Prentice Hall, Inc., 1991.
There are dozens of books on developing Windows and Macintosh programs, but few from an object-oriented perspective. As the Microsoft foundation classes become more popular, there will be more and more books describing how to create Windows programs using this system. The Think C and Symantec C++ libraries have been very successful on the Mac, and there are a few books on that system as well.
If you are serious about learning Windows, there is one book you must consider, even though it was written for C programmers and not for C++. The absolute rock-solid bible on Windows development is
Petzold, Charles. Programming Windows 3.1, Third Edition (ISBN: 1-55615-395-3).
Microsoft Press, 1992.
Once you understand Windows, you immediately will want to look at a C++ perspective. I recommend these:
Shammas, Namir. Teach Yourself Visual C++ in 21 Days (ISBN: 0-672-30372-8).
Sams Publishing, 1993.
Kruglinski, David. Inside Visual C++ (ISBN: 1-55615-511-5). Microsoft Press, 1993.
A number of books have been published lately about writing high-quality code. I highly recommend these three:
McConnel, Steve. Code Complete (ISBN: 1-55615-484-4). Microsoft Press, 1993.
Maguire, Steve. Writing Solid Code (ISBN: 1-55615-551-4). Microsoft Press, 1993.
Thielen, David. No Bugs! Delivering Error-Free Code in C and C++
(ISBN: 0-201-60890-1). Addison-Wesley Publishing, 1992.
Reading all these books and more is vitally important, and going online will give you day-to-day access to other C++ programmers. There is one more thing you can do to strengthen your skills: subscribe to a good magazine on C++ programming. The absolute best magazine of this kind, in my opinion, is C++ Report from SIGS Publishing (Sigs Publications, P.O. Box 2031, Langhorne, PA 19047-9700). Every issue is packed with useful articles. Save them; what you don't care about today will become critically important tomorrow. I have no affiliation with the magazine (I work for two other publishers!) but their magazine is the best, bar none.
If you have comments, suggestions, or ideas about this book or other books, I would love to hear them. Please write to me on Interchange, or on the Internet at jl@ichange.com. I look forward to hearing from you.
Today you learned what version control systems are and what they can do to help you keep your project organized and on track. You also learned a bit about shareware and some of the considerations in releasing commercial software. Finally, I told you about some of the online discussion groups, other books to read, and at least one very important industry journal.
Q: What is the difference between shareware and public domain?
A: Software enters the public domain when the author relinquishes the copyright that inheres to software when it is created, or when the copyright expires. Shareware is copyrighted and owned by the author but is distributed on a "pay if you like it" basis.
Q: What happens if you don't pay for shareware?
A: Your soul is consigned to the darkest and foulest regions of hell, where you must spend all of eternity listening to Led Zeppelin orchestrated for 1,001 strings.
Q: Is there any point in bothering with version control software if I work alone?
A: Yes. Version control software can help you "roll back" to a previous working version when you take a wrong turn. More important, it can help you manage various releases of your software if you are supporting more than one platform, or if you are working on Version 2 while still fixing version 1.
The Workshop provides quiz questions to help you solidify your understanding of the material covered, and exercises to provide you with experience in using what you have learned. Try to answer the quiz and exercise questions before checking the answers in Appendix A, and make sure that you understand the answers before continuing to the next chapter.
School's out; no summer assignments. No exercises for today. Enjoy and congratulations!
Go to: Table of Contents | Next Page