C Programming

Al is a DDJ contributing editor. He can be contacted at [email protected].

In my December 1998 column, I challenged readers to remember the origins of the name D-Flat as a "C Programming" column project, inaugurated in April, 1991, and continuing for about two years. D-Flat was an MS-DOS text-mode applications framework implemented first as a C function library and later wrapped in a C++ wrapper. The first reader with the correct answer would be acknowledged in this column. The results are in, and reader Bob Sundling is the winner. Bob wrote:

All I can remember offhand is that you had hoped to call D-Flat "C-Sharp" but were worried about infringing on someone's trademark. Maybe since it's written in C and looks "sharp"?

Bob's answer is close enough to earn him the coveted prize of mention in this august venue and an official DDJ T-shirt. Several readers whose entries came in later had researched their back issues or made a fast query of the DDJ CD-ROM to find my introduction to the project and explanation of the name, as follows:

Because all the really good C-oriented puns have already been taken (C-Worthy, C-scape, and so on), I will call the package "D-Flat," which is another way of saying "C-Sharp."...I will not use "C-Sharp" itself because there is almost certain to be someone out there with a trademark registration and a lawyer on the payroll.

I am happy that readers keep back issues and use the DDJ CD-ROM, but I am nonetheless gratified that the winning entry comes from someone whose memory served up the answer. When readers remember such details, it tends to attach a measure of endurance to work that I did so long ago. (Not that I have to worry about leaving a lasting legacy. Y2K and all those Cobol programs I wrote in the '60s and '70s are certain to preserve my place in history.)

Ian Ashdown gets honorable mention for being the only reader in lo these many years to identify a product named "CSharp," thus justifying my original concerns and validate my conservative naming practices. He reports that he reviewed the CSharp Realtime Toolkit in the June 1985 issue of Computer Language magazine almost six years before I was considering and rejecting the same name for my project.

To complete the meaning for those of you who are not musically inclined, C-Sharp and D-Flat are the same note on the piano.

Testing Quincy 99

Quincy 99 is the latest version of a Win32-hosted GUI IDE front-end for gnu C/C++ compilers. Quincy 99's primary purpose is to serve as the development platform for D-Flat 2000. I introduced Quincy 99 and D-Flat 2000 in December.

The original Win32 versions of Quincy (96 and 97) used a beta version of the gnu-win32 port of the gnu compilers. Sometime between that version and the egcs-1.1 mingw32 version that I am using now, the format changed for the debugging information generated by the compilers. The compilers insert debugging statements, called "stabs," as macros into the assembly-language files they generate. The assembler translates those statements into tables in the object files that describe each source code symbol and line number in the program. The changes to the stabs format were not drastic, but they were significant enough that I had to redo much of the code that processes stabs. As a part of that exercise, I substituted STL containers for the tables that Quincy's debugger uses to associate memory addresses with statement line numbers, symbols with addresses, and so on.

Quincies 96 and 97 are not without bugs, but they work well enough to support the exercises in the C/C++ tutorial book and CD-ROM for which they were originally intended. After rewriting the stabs processing code for Quincy 99, I validated the program with the suite of exercise programs from the book. At that point, I was tempted to declare victory and use Quincy 99 as it was. That would have been a mistake. Remembering my larger purpose for Quincy 99 -- to be the development environment for D-Flat 2000 -- I decided that the IDE needed a more comprehensive test than I could provide alone. None of my exercises were GUI applications, for example, so a major part of Quincy 99 was untried to any extent whatsoever. Thus a formal Quincy 99 beta test began.

Readers around the world are testing Quincy 99 as I write this column. I posted the Quincy 99 source code and binaries on my web site (http://www.midifitz.com/alstevens/quincy99/) and encouraged readers to download and test it. I recruited the first round of testers from an announcement that I posted on a mail list dedicated to the Cygnus ports of the gnu compilers. Reports from those testers have revealed bugs that my own testing did not. Some testers have suggested changes to improve Quincy 99. Others have explained how I might deal with problems that Quincy has endured since its 96 version.

Quincy and NT

One such problem was that Quincy did not work properly under Windows NT. That had always been a thorn in my side. NT users complained that Quincy would not report compile errors. There was no indication that a compile did not process to successful completion, yet the compiler generated no executable file. I responded to many such complaints by explaining that Quincy is a Windows 95 application and not validated under NT, which, I am sure, caused many readers to gnash their disgruntled teeth. Quincy launches the gnu compiler tools -- the preprocessor, compiler, assembler, linker, and librarian -- from within the IDE. Quincy uses the Win32 CreateProcess function for that launch, which permits the launched process to inherit file handles. Quincy is a Win32 GUI application, so it has no console device. The compiler tools are Win32 console applications, and they write their error messages to the stderr device. Quincy creates a text file and tells the compiler tools that the file handle represents the standard error device. The presence of error messages in the text file following a program build indicates to Quincy whether the compile is successful. Although this procedure worked flawlessly with Windows 95, no error messages were ever posted to the file under NT.

One of the fallouts of the beta test was the solution to this problem with NT. I posted the problem in the README file in the list of unsolved problems, and a tester responded. Bruce Wampler is the author of the "V C++ GUI Frameword" (http://www.objectcentral.com/). He had similar problems with VIDE, the integrated development environment he is developing with V. He told me about his solution and, between us, we got Quincy to properly direct the compiler tool error messages to a file under NT.

Having done that, I announced that Quincy now supported NT, only to hear from another tester, Roger Frank, who reported that the NT computers at the high school where he teaches programming had another problem with Quincy. You could compile any program as many times as you wanted and you could debug any program as many times as you wanted, but not both. Once you debugged the program, the compiler refused to rebuild the executable file. Quincy's debugger had the exe file locked for write access until you exited and restarted Quincy. This problem, too, occurred only under NT, and it was a puzzler. Quincy 97 did not exhibit this behavior, although 97 and 99 use the same protocols for launching debugged programs and compiler tools. The difference was found in the nature of the executables that the two IDEs launch. Quincy 97 launches programs compiled to use cygwin.dll, which implements a POSIX translation layer under Win32, and Quincy 99 launches programs compiled to use the Win32 API directly.

To the rescue came another tester. Jacob Navia is the author of the LCC-Win32 compiler system (http://www.cs.virginia.edu/~lcc-win32/) from which I extracted the resource compiler and editor to integrate with Quincy 99. Jacob had encountered similar problems with his debugger and gave me enough information to find the solution. When a program uses CreateProcess to launch another program in debug mode under NT, the launching program needs to close the launched program's hFile handle when the debug session is finished. It is still a mystery why Quincy 97 does not exhibit the same behavior. I can only speculate that something in the POSIX layer of the launched programs defeats the file lock.

By the way, there is a new version of Quincy 97 available for readers of Teach Yourself C++, Fifth Edition and the Al Stevens Cram Course on C/C++ CD-ROM. The new version works with NT. You can download it by going to http://www.midifitz.com/alstevens/quincy97/.

Conducting a test program such as Quincy 99's is a fairly straightforward process. I post each new build on the web site. Anyone who wants to be notified of the new builds sends e-mail to me saying so. I announce each new build in an e-mail message to those people on the list. If someone stumbles across the software, downloads it, and sends me a comment or a bug report, I add them to the list. Anyone who no longer wants to be annoyed by unwanted build announcements (I update the builds as often as necessary, sometimes daily) can ask to be taken off the list. This is really low-tech stuff, so I don't suggest that you duplicate these procedures to beta test a big system with a large body of testers.

Where Is D-Flat 2000?

Over the past few weeks, most of my effort has been directed at making Quincy 99 work well enough to be the development platform for D-Flat 2000, my ambitious project to build a Win32 application framework that uses Standard C++ features such as templates, exceptions, containers, and namespaces in the implementation. As a result, not even the simplest version of D-Flat 2000 is ready to be published. Not that I am neglecting the task. I have already started to write code. But that task uncovered a serious deficiency in my knowledge.

That deficiency is the product of my stubborn nature. I steadfastly refused to learn Windows programming in the days when all a programmer had was the Windows C API. I would not consider doing so until mature C++ compilers and framework class libraries were available, which, of course, eventually came to be. As a result, my knowledge of the Win32 API extends mostly to those things that MFC does not support. Fortunately, MFC does not try to raise everything to higher levels of abstraction, and an MFC programmer needs a rudimentary understanding of such things as device contexts, fonts, command messages, and so on. I say fortunately because otherwise I'd have a lot more to learn about the underlying API that I am attempting to wrap.

This all came home to me when I started to design the D-Flat 2000 window class, the top-level class in a windows hierarchy that supports document views, buttons, and so on. Virtually everything visible in a GUI application is a window. I called on my experience writing the original D-Flat and set about to design a window class that would encapsulate the behavior that all windows have in common. Whereupon I stopped dead. D-Flat had to do it all. There was nothing underneath except some hardware and BIOS. D-Flat 2000 has (spoken in the vaporware tense) Win32 at its foundation. To know what to wrap and what to implement, I need to know what the foundation already does. I already knew that the API supports displaying windows based on window classes (in the pre-C++ API vernacular; not C++ classes) that the programmer provides. But I found myself adding a data structure to support the relationship between parent and child windows, and it occurred to me that the API probably already does that. So here I am, several years later, learning what I vowed never to learn -- how to program a Windows application in C so that I know what the API provides and what I have to provide. One step forward, two back.

From the D-Flat 2000 Design Notebook

The following paragraphs come from my design notes. I provide them here so that you can ride along with me on the winds of whim. Please react as critically as you wish to anything you see here. This is the beginning of the project, and you have the opportunity to influence the outcome. Flame away.

D-Flat 2000 does not revolutionize the user interface paradigm. Applications look to the user like traditional Windows applications with documents and views, menus and dialogs, and so on.

D-Flat 2000 takes a different view of the application from the programmer's perspective. Abstractions can be expressed with templates. Conceptually, a D-Flat 2000 application is a bag that contains an application window, menus, toolbars, dialogs, documents, and so on. Unlike STL containers, wherein each instantiation contains only objects of a single type, a bag instantiation can contain different kinds of objects. No such container is implemented in Standard C++ unless you consider an STL bag to be a standard container that contains pointers to different kinds of objects derived from a common base class. Standard C++'s run-time type information supports such a concept by allowing the program to determine at run time the type of an object retrieved through a reference taken from the container.

Goal: Wrap only the user interface and leave the rest to the Win32 API. Eventually add other APIs (multimedia, telephony, serial communications, and so on) as needed and as time permits.

Encapsulate the view paradigm within the document paradigm. MFC does a marginal job associating documents and their views, and the code idioms for getting a view from a document are cumbersome.

Find a better paradigm for capturing command messages. An MFC programmer is not always sure whether a particular menu/toolbar command message should be processed by the view class, the document class, the application class, or the frame window class.

Why should the application class and its frame window be separated, other than to differentiate between document-based and dialog-based applications? DFWrap, the C++ wrapper around the original C D-Flat library, integrates an application and its window. Why not use inheritance to implement the two different application behaviors?

Goal: Find an alternative to Hungarian notation.

Hungarian Notation

I never really liked Hungarian notation, an identifier naming convention that encodes identifiers with a prefix that specifies the type of the object associated with the identifier. You can read about Hungarian notation at http://ivory.lm.com/ ~gregleg/hungarian.html. I have used subsets and supersets of it because something told me I should be conforming to Windows programming conventions when I write a Windows program, and MFC uses it extensively, applying a superset to accommodate the C++ language. (One MFC extension is the use of the m_ prefix to differentiate between data members and other variables in member functions.)

To not use Hungarian notation in an MFC program is to have a hodgepodge of identifers with no apparent convention of conformity. How important is that? I don't know. Others are passionate about naming conventions and I am not, but the D-Flat 2000 project provides an opportunity to use something other than Hungarian notation. The C++ namespace feature will surely influence whatever convention, if any, falls out of this project. And if namespaces have any redeeming quality at all, it is that they might contribute to a viable alternative to what Ray Duncan calls "the Hungarian gibberish."

Years ago at a programmer's convention, I was on a C++ panel that included Bjarne Stroustrup, P.J. Plauger, Jim Coplien, and other C++ luminaries. A programmer from the audience asked for the panel's opinion about what he should do when his management insisted on mandating coding conventions such as Hungarian notation. Dr. Stroustrup's quick response was, "Could you find another job?"

DDJ