Dear CUJ,
Regarding Jim Hyslop and Herb Sutter's "Conversations" about "Factor Redux, Part 1" (CUJ, July 2003), I would like to point out a situation where the class factory silently fails.
Following the downloaded example and comments in the factory.h source code, I placed the registration objects at file scope in the class implementation file. To my surprise, no classes were being registered in the factory.
In my case, the class implementation files were in a statically linked library file. Examining the lib file showed the symbol for the registration object was in the lib, but a search of the symbol map from the linker revealed that the registration object had not been linked into the exe.
Of course! The linker only brings in the symbols that the exe requires and tosses the rest. Since the registration object was not referenced outside the lib, it was never linked in and, therefore, never instantiated. For this to work, the registration object will have to be instantiated or referenced by something outside the lib. Quite inconvenient.
It would be kind to your readers to point out this little gotcha. It sure got me. I suppose that this issue of template class instantiation in a lib is a general weakness of C++ templates that programmers should be more aware of.
Bryan Leppard
Jim replies: Thanks for writing, Bryan. You are quite right about the static library problem. This issue is not limited to the factory, either—any program that deals strictly with a polymorphic base class, where a derived class is in a statically linked library, suffers the same problem.
Unfortunately, these linking issues are outside the scope of the Standard, and we try to present Standard C++ as much as possible in "Conversations." At least, that was the intent at the time of writing, but now that I say it to you, it does sound like a cop out. You are right, we should have acknowledged the problem, at least in a footnote. In "Creating Truly Maintainable Class Factories" (CUJ, November 2000), Early Ehlinger presented a slightly different factory that uses DLLs or .so files (depending on your operating system) to achieve the same effect. There is also a brief discussion of his article in Usenet; search google for "derived class not linking in static library" (without the quotes).
There are workarounds, none of which are particularly palatable. For example, many compilers provide a means to force the linker to link in certain symbols, whether those symbols appear to be referenced or not. Unfortunately, this means you have to list each object file that needs to be linked in—and you have to modify that list each time a new derived class is added. In some compilers, you also have to provide the decorated name of the symbol.
Bryan responds: In this case, my solution was to put all the registrations in a single class and create an instance of that class outside the lib to force linkage. Not as nice as the "registration in the implementation file" technique, but a lot better than monkeying with compiler/linker settings.
Dear CUJ,
I would agree with Chuck Allison that software has too many bugs due to many factors, but his "Editor's Forum" (CUJ, July 2003) missed one important issue—software has more moving parts than a space shuttle. If you consider that each line or statement of a program is a separate part, the complexity of some software is beyond any other human creation.
One of the difficulties of making software reliable is that a single defect is a defect in every installation of that software. If a tire manufacturer fails to make a good tire, a car can crash and the tire manufacturer could make a payoff to keep it quiet. But if a programmer were making a virtual tire with a defect, all of the virtual cars that used it would crash. They would probably all crash at the same time if they were on the same road at the same time. The conditions to cause a crash are at least as unpredictable as those that cause a tire to fail.
Software is totally different from a manufactured part. It is not a car and it is not a space shuttle. To make software as reliable as the other things we create, the price will have to go up by many orders of magnitude. Current office suites sell for under $1000; but with the amount of development and testing needed to make them as robust as automobiles, it [would] end up costing the user $10,000 or more. Maybe much more. The software market will not bear that, and any who try to make software that they can guarantee will be put out of business by the companies that are willing to have an "as-is" license agreement. Users decide how reliable it is by making their purchase. Programmers are obligated to make products that make their company profitable.
Programmers don't work at jobs where they can write software as well as they want to. Nothing new would get done and the old stuff from 20 years ago would now finally be making it's way towards 99.999 percent reliability. It's a grand ideal to want more reliability, but it's hard to achieve in a capitalistic society.
David Rector
Chuck replies: David, thanks for writing. Just as you mostly agree with me, so do I with you. Admittedly, software is, by nature, complex. I have, however, worked at more than one company where I was able to write software to the best of my ability. It was a treat, indeed, and one team I worked on continually surprised itself on how well it performed and how fast we turned around changes and updates. I confess that we were not producing shrink-wrapped software, but rather internal systems for corporate infrastructure. The theme of my recent "Editor's Forums" is not so much to point out a lack of perfection, but to convince many that great improvements can be made with a moderate increase of diligence and wisdom on the part of managers and developers alike. Having been part of such fortunate circumstances, I'd like to see it catch on. I still believe that even producers of commercial software products can do better with only a marginal cost increase (because they can design, code, and manage better than they do now with little or no financial investment), and that their license agreements should reflect more confidence in the quality of their products. Thanks for your insightful perspective.