Dr. Dobb's Journal January 1998
Al is a DDJ contributing editor. He can be contacted at astevens@ddj.com.Two years ago, I told the story of how a prominent software tools vendor refused to give Judy a T-shirt at a party that the vendor hosted at SD '95 East, one of the popular Software Development series of programming conferences. As a result of that column, the contrite vendor sent a sincere apology and a care package containing two T-shirts, two propeller beanies, and a yo-yo. This generous gesture restored Judy's faith in her ability to exploit my prominence in the trade media to effectively schmooze vendors.
We recently attended SD '97 East in Washington, D.C. Judy was certain that her prominent Dr. Dobb's Journal badge would never be snubbed again, particularly since I had been elevated from a mere speaker to a keynote address. While I went about my business looking for new products to report about, she happily cruised the show floor collecting free pens, mouse pads, and sundry toys and collectibles.
Oh, how history repeats itself. I could tell something was amiss when I saw Judy's approach from across the crowded floor. You can see Judy's ire coming. It has a set to its jaw and a stride to its gait. I braced myself.
"It happened again," she said and pointed to a booth where they were handing out T-shirts.
I gasped. It was the Miller Freeman booth. Miller Freeman is the show host and the publisher of this and many other magazines. In short, my bosses, my mentors, the good folks by whose graces I write this column, travel to interesting places, and get to rub elbows with such industry icons as Bill Gates, Philippe Kahn, and J.D. Hildebrand.
"They said the T-shirts were for paid attendees only," she said. "I told them that you were being paid a lot of money to be here, which makes you a paid attendee if anyone is, but it made no difference."
A long pause followed as I waited for the bomb to drop. "Heads will roll for this," she snarled and turned toward the exit.
I always enjoy the east coast edition of SD because Washington, D.C., is my home town, and I'll gladly take any opportunity to return. I grew up in a Virginia suburb and D.C. was my stomping grounds as soon as my parents let me out on my own. My first programming job was in D.C. and it's also where I went to college and developed as a professional musician. While in school, I used the Library of Congress to research writing assignments. Back then anyone could walk into the Main Reading Room and ask for a copy of any book, magazine, or newspaper that had ever been published in America. You could not check out books or periodicals, but you could read them in the quiet Main Reading Room until closing time. That room was, to this young man, a highly spiritual place. Imagine being able to read virtually anything in print from any period in history just for the asking.
The Main Reading Room was a circular room with a high dome ceiling, gold plating, lavishly decorated arches, and paintings and statues representing the work of 42 American artists. Through the arches you could see stacks of books representing the nation's treasure of information in print. The reading desks and card files were organized in a circle surrounding the librarians' station, a large circular desk in the center of the room. In 1964 and '65, they renovated the Main Reading Room, sacrificing some of its charm to the contemporary problems of information retrieval. Then, in 1986, an extensive restoration was undertaken along with restorations of the rest of the Thomas Jefferson Building, which includes the Main Reading Room. Now the library is open again to the public, restored to its earlier glory, and the details of its restoration are breathtaking. It is far more beautiful than I remember it, because the inlays, paintings, and sculptures were covered with over a half-century of dust and buildup, and their colors and details were obscured by time. The restoration meticulously cleaned and restored every detail, and the public areas now appear much as they did when the present housing for the Library of Congress opened in 1897. You can visit it at http://lcweb.loc.gov/loc/legacy/bldgs.html but to appreciate its true magnificence, you have to see the real thing.
There was not much new for C/C++ programmers at SD '97, Java and web-developer tools being the stars of the show. What used to be the Software Developer's conference is now divided into two conferences, SD '97 and Web '97 reflecting the rapid growth of interest in web development. The two conferences share one exposition, which is appropriate because many vendors support both disciplines.
A prominent phenomenon at the exposition was the profusion of vendors with products that support version control, more than I have seen at previous conferences. I've never used a version control package and have never felt the need for one, always managing source baselines and version releases through the judicious application of manual procedures by conscientious people. But the projects I typically work on are small by comparison to what many programming staffs do, and I wondered what has happened in that sector of the industry to create a market for so many version control products. Maybe I can guess.
Every programming generation includes application developers who use tools specifically designed to raise the levels of abstraction to their highest -- tools that are intended to make programming easy enough for nonprogrammers to do. Such dumbed-down developer tools permit nonprogrammers or near programmers to develop relatively simple applications. They also permit experienced programmers to develop more complex applications in rapid prototyping environments, sacrificing performance and features for speed of development. In the 1960s, RPG languages and Cobol tried to be that tool and failed; you needed real programmers to use them effectively. In the 1970s, it was Basic, which also failed to replace programmers because real programmer skills were still required to build all but the simplest of applications. The 1980s gave us dBase. The early 1990s brought Visual Basic. Now, web developers have scripts implemented in the languages of HTML, JavaScript, and Perl. What sets contemporary web developer tools apart from the no-brainer tools of previous generations is that so many more people are using them. I know a tuba player who decided to "get into computers" and within a few months found a well-paying job as an HTML page designer. For the first time, the for-dummies tool programmers seem to outnumber the professionals. Version control might be more necessary than ever before because there are more programmers with less experience developing more applications. All that code is bound to get out of control.
If this discussion sounds like I am talking down to web developers, I apologize to them. I am not talking to them at all; I am talking to the C and C++ programmers who read this column. We know what programming is. To quote my pal Richard Hale Shaw, "Real programmers terminate every statement with a semicolon."
Bjarne Stroustrup was one of the SD '97 keynote speakers, but I was unable to attend his session. He gave me a quick rundown of his topic during a chance meeting in a corridor. He jokingly referred to his keynote as his arm-waving speech, which he agreed to do only if they permitted him to conduct a smaller, closed session with experienced C++ programmers who wanted to go one-on-one with The Man.
I could not attend Bjarne's keynote address because I was giving one of my own at a miniconference on software developer careers. This event was a milestone in my public speaking career because I had never before been invited to give a keynote address at a major industry conference. I thought myself an odd choice to talk to programmers about getting jobs since I haven't had one in almost 20 years, what with freelance programming, writing, and piano playing having sufficed to keep Judy well-supplied with tote bags and screen savers. The keynote audience was somewhat unmatched to my assigned topic, too; I asked for a show of hands of those who were looking for jobs or employees, and few of them were. So, current employment not being at issue, I used the occasion to reflect on how programming jobs have changed since 1958 when I first got one. Most of the audience stayed for the duration, didn't throw any aged vegetables, or ask any hard questions, and most of them applauded when I stopped talking (perhaps as a gesture of relief). So, by those measures, my maiden keynote address was a resounding success.
I recently received a review copy of a product named CodeWizard from ParaSoft Corp. (http://www.parasoft.com/). CodeWizard is an interesting product that performs diagnostic analysis of C++ source code. The Windows 95 version installs into the Visual C++ Developer Studio and analyzes the C++ code in a Developer Studio project. That is the version I tested. There are also command-line versions of CodeWizard for Alpha, HP, Linux, RS/6000, SCO, SGI, Solaris, and SunOS.
What makes CodeWizard interesting is that its diagnostic checks are based on the C++ programming guidelines documented by Scott Meyers in his books, Effective C++ and its sequel, More Effective C++, both published by Addison-Wesley. The product package includes copies of the books. Effective C++ is now available in a second edition, but the review copy sent to me had the first edition, probably because the newer edition was only recently released.
In the interest of accuracy I should emphasize that Scott neither endorses nor disapproves of CodeWizard nor does he have any vested interest in its success other than whatever royalties he earns on the books that ParaSoft includes with the product. Scott says, "I endorse the idea of the product, and I encourage people to try it and others like it."
The two books describe 85 individual guidelines for writing robust C++ programs. CodeWizard parses the code to find violations of many of these guidelines. I did not attempt to run a comprehensive test to see which of the guidelines CodeWizard tests for and which it does not. That would involve writing programs with 85 violations, and I don't see the point in that. Instead, I did what any programmer would do -- I ran CodeWizard against several of my Visual C++ products to see if it could catch any bad habits. This might not be as exhaustive a test as a reviewer should make, particularly since my code has been influenced by Scott's work for several years, and I intuitively avoid many of the violations that CodeWizard would catch. Nonetheless, I decided that if CodeWizard uncovered any bad habits creeping into my programming, it would earn its keep and my endorsement. It did. I found it to be quite effective in many ways. In one respect, CodeWizard is like a periodic test flight for a pilot in that it reveals subconsciously acquired bad work habits. In another, it's like a word processor's grammar checker in that it calls attention to practices that might be okay in some cases but that need to be looked at in others.
The Visual C++ version of CodeWizard is new and is based on earlier versions that support UNIX platforms. The manual that came with the review copy does not even mention a Windows version. CodeWizard's integration with Developer Studio is well implemented, however. CodeWizard commands appear on the Tools menu, and its output is written to three new tabbed text displays that are added to Developer Studio's Output window. The only indication of a hasty port is the unnecessary console window that displays when you open the CodeWizard Control Panel. I suspect that the window will go away in future versions.
Many of the violations in my projects were found in code that Developer Studio's wizards generate. One such violation that appears consistently is the use of old-style casts. Microsoft's wizards are a little behind the times, it seems. A control panel allows you to suppress certain diagnostics and to bypass selected files. There's no point in parsing all the compiler's header files, for example, and the default is to bypass them. You might be tempted to suppress some warnings, particularly the ones about wizard-generated code, but I prefer to leave them all on. Every now and then a warning points me to a rule that I have forgotten, and I am grateful for the reminder.
My only criticism of CodeWizard has to do with persistence, and it's a common problem with makefile-driven tools. CodeWizard's installation procedure adds commands to Developer Studio's Tools menu. One of those commands analyzes all files in the project except, of course, suppressed files. This procedure launches CodeWizard in independent executions to analyze each file as listed in the makefile. Successive executions, however, do not remember which header files have already been parsed and reported in the current project analysis run, so violation messages for a header file are repeated for the analysis of every .cpp file that includes that header file. It should be a simple matter to record somewhere which header files have been analyzed and suppress repetitious reports of its violations. Repeated analysis of the header files are necessary in order to provide context for the analysis of .cpp files, but repeated display of the messages is not only unnecessary, it's annoying. To be fair, I should add that I have the same criticism of most compiler environments, including Visual C++.
CodeWizard is slow. It takes a long time to analyze a project. That in itself is not a big problem because you wouldn't run CodeWizard every day against a project. But, to address the issue of performance, ParaSoft is working on precompiled header-file logic to speed up the analysis. Perhaps at the same time they will add code to suppress duplicate warnings.
My only other complaint is the name. I don't know which product came first, but a few months ago, I reported a compiler product named CodeWarrior and that name stuck in my head. While writing this column, I kept typing CodeWarrior where I meant CodeWizard. Now I have to look at the boxes to see which product has which name. This is the kind of confusion that makes trademark lawyers happy.
These few criticisms are minor. On the whole, CodeWizard is a useful and valuable tool. It automates the wisdom that Scott Meyers teaches and has the potential of making better programmers out of most of us. I highly recommend it.
A few months ago, I wrote about the emerging C++ Standard specification and the activities of the ANSI/ISO committee of volunteers who have undertaken that monumental task. I got a lot of mail about that column, most of it agreeing with me. Just because you agree with me, though, does not make me right. Some members of the committee were delighted with my comments, and others were offended, which indicates that I hit a few nerves. Bjarne Stroustrup heard about the controversy and asked me about it. I sent him a copy of the column, and he sent me his comments. He felt that I had reported only one side of several issues that have divided the committee into factions; it was as if I had been briefed by only one of the factions. My report can be viewed from three perspectives, which I will address here.
First, what I wrote about the C++ language and library, as they are currently defined in the draft standard document, reflects my opinion of that specification according to what I read in the document and my experience with C++, and not what members of any polarizing factions have said to me.
Second, my interpretation of what seem to be specification ambiguities and design compromises -- header files, library functions, namespaces, and so on -- are also based on the contents of the document rather than the opinions of others.
About those first two points: I formed my opinions during an exercise wherein I wrote about 300 small example programs that demonstrate the behavior of the language and library for a C++ tutorial work. This exercise included modifying the GNU compiler and library so that they seem to conform to the draft specification even where they do not. The exercise necessarily involved a close reading of the December 1996 Draft -- looking everywhere for any reference to any topic. It may very well be that I have read the Draft as closely and understand its contents as comprehensively as most of its authors, the committee members.
Now for the third point: My reporting of committee events and activities surrounding these issues is indeed based on what I have been told. I am not a member and have never attended a meeting, although I have read some of the minutes. I do not know what the factions are, nor which members belong to which factions. The minutes rarely reveal such details, and I do not desire to know about them. I am more interested in language and library issues than personalities and conflict. However, in the interest of fairness and balance, I am publishing Bjarne's comments here with his permission and without responding to them because I believe them to be true and unbiased. Bjarne is a thoughtful and considerate man. He said he wanted to enlighten me, not embarrass me, and seemed concerned that his comments might do the latter. If that happens, so be it. This missive was not a letter to the editor; Bjarne framed his comments as private and informal correspondence to me. I edited them only to remove personal statements that do not contribute to the points he wished to make. His first comment was in response to my implication that the templatized version of iostreams was influenced by the newly introduced STL generic programming model. The other comments should be apparent as to what they address.
From Bjarne:
...the templatization of iostreams was independent of the STL and proposed and primarily worked out by the Japanese. The Japanese had been looking for a way of handling wide character streams as wide character streams rather than as encodings of character streams for years.
You conjecture that "some faction will probably push again to add the SGI containers." That didn't happen, and I would have been very surprised and probably a bit angry had it happened. It is more than a year since any new containers were proposed, and those were rejected -- fair and square -- because it was too late to add them. I know of no one on the committee who didn't abide by that decision; that is, I have heard absolutely no lobbying on that issue since. Comments like yours on this issue are annoying because they suggest instability, political infighting, and broken process where none exist; other areas have been contentious, but your first "shot" went wild.
"Deprecate": The C++ committee didn't invent this usage. It is standardese. I'm sure some...ISO document defines it precisely, but the committee was told -- as was the C committee -- that features that we thought the language would be better without but that we didn't feel we could ban should be deemed "deprecated." There is a host of such ISO/ANSI terms, such as "normative." They are a nuisance and occasionally an affront to native English speakers, but a necessity in an area where translation into another natural language without loss of information is considered extremely important. I don't think that's actually easy, and I heartily dislike some of the ISO rules and some of the ISO/ANSI terminology, but the committee must follow ANSI/ISO rules if it wants anything accomplished.
[Quoting from the column:] "Compiler vendors are reluctant to implement drastic changes to proposed standards; their substantial development investments can be negated in a single moment of random, unanticipated vote from the floor." This is really misleading. I know of no major language or library feature that has been withdrawn after it has been present in a draft standard. In two cases, I had to throw my full weight against a proposal that would otherwise have passed to stop that from happening. Major changes took about a year of preparation to reach a vote. Calling that "random, unanticipated" is factually wrong in addition to being unfair.
As it happened, I was in favor of having both <iostream.h> and <iostream>, but I can't be everywhere, and the majority opinion was that implementation purveyors would provide <iostream.h> anyway for transition, that we should minimize explicitly deprecated stuff, and that if we mentioned <iostream.h> we would have to specify what was in it (a problem that in theory doesn't exist for <stdio.h>), and how the existing <iostream.h>s differ.
Last August I wrote about attending Jim McCarthy's TeamworX BootCamp. Jim was at SD '97 to give a presentation, and we were both delighted when our friend from Bootcamp, Marine Corps Major Buzz Lightyear paid us a surprise visit. He was in town to brief a general at the multisided mausoleum and made a side trip to SD '97. Buzz and I burned the midnight oil over some controlled red liquid substance while he let me in on his secret plans for The Killer App of the next century, something that has never been done but that most computer users will buy. He's not sure he can build it, but I can promise you, if he builds it, they will come. Watch for the Buzz Lightyear simulation sometime after the year 2000. I wish I could tell you more, but this much I can say: I'm already signed up to be a beta tester.
DDJ