C-Set++ 2.1 Review
Written by Gordon Zeglinski
At long last the infamous C-Set++ 2.1 CD-ROM has arrived! Was it worth the wait?
This column will look at the new features in C-Set++ 2.1, and then benchmark the compiler against the Watcom C/C++ v9.5a compiler using POV version 2.1 and a mini-application from numerical analysis. POV has been chosen as a test program because its source is freely available and it is fairly popular.
Contents
What's New?
The new features in C-Set++ 2.1 are:
- WorkFrame version 2.1
- Drag-and-drop support to the User Interface Class Libs
- KASE:Set
Bundled features in C-Set++ 2.1 are:
- CSD Level 002 applied to the compiler, tools, and the user interface class libraries.
- Toolkit 2.1
Note: by now, the compiler is at CSD level 005, and the user interface class libs are at CSD level 003.
WorkFrame Version 2.1
The new WorkFrame (WF for short) is nothing short of pure WPS magic. As with most magic, it doesn't always work though. Before getting to the disappointing stuff, let's look at the new whiz-bang features.
The new WF is totally different that the older versions of the WF. It introduces several new WPS objects, two of which are, the WorkFrame/2 Project and the WorkFrame/2 Composite Project. The WorkFrame/2 Project is roughly analogous to the projects in WF version 1.x.
The new projects are enhanced to allow source files being located in multiple directories, and it has a more intelligent make file creator. At last, the make file creator "remembers" which files have been previously selected, and what actions to perform on them! The WorkFrame/2 Composite Project objects allows multiple targets to be maked at once or in sequence. Typically, these multiple targets (or projects in WF terminology) are the various components of the application like DLL's, help files, etc.
The best feature in the new WF is its make file creator. It not only remembers previous selections, but also masks out files whose extensions don't match the actions you are doing. For instance, suppose, you are compiling and linking your code; only files matching the masks of *.C, *.CPP, etc. would be shown in the file list of the makefile creator.
Like the previous versions, version 2.1 is still compiler independent. It uses objects called Actions Profiles to provide a WPS front end to the actions a tool can perform.
On to the bad part, the WPS is not 100% bug free. Thus, any of its bugs will affect the WF. On top of that, the WF isn't 100% bug free either. Numerous warning message boxes have popped up telling me that some unknown detached processed has generated some sort of exception and that it should be terminated.
These, however, are not too bad as OS/2 is quite capable of surviving them. The more serious bugs will actually hang OS/2. Most PM developers are aware of how fragile the message dispatch thread is to exceptions. The easiest way to hang PM is to have an exception occur in this thread. The WF unfortunately has a few of these bugs too. Also, the migrate option in the new WF doesn't migrate all of my old WF 1.1 projects.
Overall, the new WF is a big improvement over WF 1.1, but is also a bit less stable. I'm sure it will improve over time.
Drag and Drop Support to the User Interface Class Libraries
Basically, this is an extension to the user interface class libs that shipped with C-Set++ 2.0. It is comprised of several new classes which encapsulate OS/2's drag and drop mechanism. This topic in itself could cover several issues, so I'll not get into any details here but rather save it for a future column or two. For those who can't wait, the C-Set distribution includes several sample programs that illustrate their use and some documentation on them.
KASE:Set
This is the most disappointing part of the package simply because my expectations were high. This package makes use of existing IBM supplied tools for editing dialog resources, bitmaps, and icons. It does provide a built-in menu editor, but I found it a bit awkward to use. This product can't be used to generate many of today's applications due to it's limitations. However, some people may find it fun to play with. The Guidelines product, which has a one free copy per organization license, is better for those interested in code generating tools.
Note: Guidelines also requires C-Set++ at present
IPMD
IPMD is the debugger included with the C-Set++ 2.1 (and the C-Set++ FirstStep) package. Although it is the same debugger that is mentioned in my previous compiler showdown, many debugger features were not discussed in that issue because of the number of compiler packages looked at. We will look at some of these features here.
The debugger is PM based and is equipped with many features designed to help debug PM based applications. It has message queue monitor that can be used to display the PM messages being sent to an application. These messages can be filtered on the bases of the window they are going to, the message queue they are sent to, and by the actual message. A nice feature here is that you can specify how your custom messages are displayed.
For instance, if your application has defined the message WM_USER+1 as MSG_MY_MESSAGE, you can configure IPMD to display MSG_MY_MESSAGE as the message instead of the number given by WM_USER+1. In addition, the message parameters are displayed in a form that represents their interpretation for the given message. If a message specifies that paramater 1 holds two SHORTs, IPMD will display the message as two short integers. Another nice feature for PM programmers is the window analysis views. In these views, all the details about the windows an application has created are shown.
For C++ programmers, the debugger includes a hierarchy browser. The real value in this browser is realized when you are using class libraries written by other people. The hierarchy can be viewed in a graphical form, and explored in a textual form.
As expected, the debugger includes all the features common to debuggers in general,, ncluding, variable viewers/modifiers, break points, etc. But one feature I haven't seem on a PC-based debugger is it's ability to save the debug state when you exit the debugger. Saving the debug state saves the breakpoints, open source code views, and various monitor windows (the PM message monitor, variable monitor, etc.). This feature is of use to both PM and non-PM programmers alike.
On with the Benchmarks.
As I mentioned before, POV 2.1 will be used as the test program for these benchmarks. Both compile times and execution times will be measured. In addition to POV 2.1, a specialized heat transfer application based on the finite difference method will also be tested. For the curious, makefiles for the C-Set++ and Watcom compilers are included.
POV 2.1 test
First, let's look at the code generation. The following table presents the results from this first test:
| Compiler | Compile Time | Executable Size |
|---|---|---|
| Watcom C/C++ 9.5a | 6 min 20 sec | 239006 |
| C-Set++ CSD005 | 4 min 42 sec | 343040 |
Now let's look at the time it takes to trace the following scene:
The above scene is the result of test 1. Test 1 traces the scene into a 200x200 image using antialiasing. Test 2 traces the same scene into a 100x100 image without antialiasing.
| Test Number | Watcom Time | C-Set++ Time | ratio: Watcom/C-Set++ |
|---|---|---|---|
| 1 | 59 min 8 sec | 46 min 2 sec | 1.28 |
| 2 | 2 min 17 sec | 1 min 45 sec | 1.30 |
| Data | Data | Data | Data |
Heat Transfer App. Test
The heat transfer application is based around the Gauss-Seidel iterative method for solving matrix systems. The code is not object-oriented, but it makes use of a few C++ specific features. The Gauss-Seidel method is quite common in certain areas of numerical analysis; thus, it was included in this comparison to reflect a real world application.
| Compiler | Compile Time | Executable Size |
|---|---|---|
| Watcom C/C++ 9.5a | 48/46 sec | 44290 |
| C-Set++ CSD005 | 41/37 sec | 73716 |
The compile times given are in the form of first compile/second compile. The first compile refers the first time the compiler is executed within the VIO window. The second refers the second time the compiler is executed within the same VIO window. This was done, because this application comprises of only one fairly small source file. A better feel for the compile time can be achieved by averaging the two times.
The execution time shown below, is for a 216x216 matrix.
| Compiler | Execution Time |
|---|---|
| Watcom C/C++ 9.5a | 27 sec |
| C-Set++ CSD005 | 31 sec |
Notes For The Curious
The heat transfer program will prompt you to enter the number of nodes in the X and Y directions. The number of nodes must follow the following equations:
NODES =(3/N)+1
x
NODES =(1/N)+1
y
N must be less than or equal to 0.5 and 1/N must be an integer.
The program will also prompt you for the value of k and H. Any non zero value can be used for these two variables.
Bits and Pieces
The tests were performed on a 486 DX2-66 based system with 128K external cache and 16M of main RAM. The execution times and compile times were measured after rebooting OS/2 except where noted otherwise.
Two zip files are included with this column. pov.zip includes the makefile for the watcom version of POV for OS/2. The file heat.zip includes the executables, source code, and makefiles for the program used in the heat transfer application test.
Summary
For a C-Set++ 2.0 owner, the real value of the C-Set++ 2.1 package lies in it's inclusion of the new WorkFrame, the drag and drop support objects in the user interface library, and the 2.1 toolkit. Although C-Set++ generates code that is somewhat larger than that generated by the Watcom compiler, it may or may not be faster than the Watcom compiler. Your mileage will vary depending on the application.
More importantly, there are cases where the speed of the executable is not important. This is especially true, in applications which depend heavily on user interaction or those which are I/O-bound. When developing PM applications, the quality of the support tools is just as important as the quality of the compiler. Without a good PM aware debugger, discovering why a PM application is not behaving as expected would more be difficult.
