Feedback Search Top Backward Forward

A Review of VisualAge C++ Version 4.0

Written by Gordon Zeglinski




In this article I will review VisualAge C++ (VAC++ for short) version 4.0 for OS/2. The computer used to test the program has 128 megabytes of RAM and a 200-MHz Pentium processor.

The VAC++ package includes 4 compilers: 1 command-line and 1 IDE- based compiler for both OS/2 and Windows NT. The command-line compilers are included for compatibility with older code and code originally written for different compilers. A full install of either compiler would require about 600 megabytes of hard-drive space. A full install without the IBM Open Class Library source code will occupy fewer than 340 megabytes of hard-drive space.

I have tested both the OS/2 and NT versions of the IDE-based compiler but will limit this review to the one for OS/2.

What's New?

Most of the new features are in the IDE-based compiler, which this review will focus on. The IDE has a totally integrated debugger, compiler, and browser. Code can be edited and breakpoints set from inside the debugger or any of the browser windows (that display source code). The compiler supports the complete ANSI/ISO 1998 C++ standard. Additionally, the IDE utilizes an incremental compiler and linker. Figure 1 shows the IDE overview windowpane.

Figure 1. Overview Window

The build environment is totally different from traditional compilers. The concept of header files and source code files is obsolete. VAC++ utilizes a global approach to definitions and implementations. That is, once a definition is processed it stays in memory for the duration of the build. To maintain compatibility, header files can still be #included. This new approach to handling source code is disorienting at first and will make migrating existing code to the compiler somewhat difficult. Errors pertaining to objects being defined more than once will likely occur while migrating. Often these errors are incorrect. The work around is to remove the #include line in the source file that contains the offending “redefinition”.

The help system is implemented using a custom WWW server. Any frames-compatible browser can be used to connect to the server and view the help and online documentation. Needless to say, all documentation is done via html. The documentation is pretty good. I would have liked to find a single section that listed all of the differences between versions 4.0 and 3.x.

Additional documentation is shipped in pdf files. The C++ Programming Language, Third Edition by Bjarne Stroustrup is included in pdf form. Personally I don't like reading pdf files on the computer. This book is divided into several pdf files, making it impossible to search for keywords. It's not possible to print a section off for easy reading away from the computer. Overall, I found the usefulness of this to be limited. On the other hand, the pdf files specifically for VAC++ vary in quality. Some are formatted nicely for printing while others have close to a 3-inch margin at the bottom of the page.

Testing The IDE

To test the compiler, I migrated some existing cross-platform (OS/2 and NT) code written for previous versions of VAC++ to version 4.0 (with service pack 1 installed). Migrating the code took about 2 days. Most of that time was spent tinkering with the code and researching error messages to get it to compile. Even after the code was compiling, I never got it actually working. Yes, it was working fine in previous versions. I'm not going to go into any depth on how to migrate code. As the review unfolds, I will point out some of the pitfalls I found and discuss the bugs that prevented the code from executing.

After creating a new project, source files have to be added to the target. Figure 2 shows the project configuration window. From here the various build options can be set and source files can be added. I ran into difficulties with the compiler complaining about classes being defined more than once. This was fixed commenting out some #include statements in the source .cpp file where the error was occurring.

Figure 2. Configuration Window

Notice that header files have been added as source files for Test.exe. This was done by the configuration optimizer. The configuration optimizer was executed after the project was compiling successfully.

The message window, shown in Figure 3, allows quick access to code that has compile-time errors or warning. In this figure, the socket calls are undefined because the proper libraries were not linked in.

Figure 3. Message Window

The integrated browser allows quick and easy viewing of classes within a project. Figure 4 shows the class browser. When a class, in the upper left windowpane, is selected, the upper right windowpane shows the class definition. The lower windowpane displays the source code for the class element selected in the upper right windowpane.

Figure 4. Class Browser Window

The class hierarchy browser is shown in Figure 5.

Figure 5. Class Browser Window

The most improved feature in VAC++ is the way it handles class templates. There is no need to create special implementation source files or to specify special link-time options. Simply include the source code file for the template class's member functions in the list of source files for the target. The compiler does the rest. The browser windows will display template classes with and without the substituted template arguments. Consider the following code.

     template class foo{ t val;};
     foo x;
     foo y;

This example will cause the browsers to display information for foo, foo, and foo. However they do not substitute the template arguments into the browsed class code, which would make this feature more useful. In other words, when browsing the foo class, the browser displays the class definition with t instead of int substituted for t.

Now that we've seen most of the interface, we can get into how well the compiler works. The initial build time is fairly long. If the machine has enough RAM (128 megabytes is a must-have), the length of the compile is totally dependent on the speed of the CPU. A 200-MHz Pentium is on the slow side. The IDE takes a noticeable amount of time to simply repaint. I would consider a 300-MHz CPU to be the slowest for practical purposes. Once the initial build is complete, a recompile can take as little as 30 seconds. If the source for only one function is changed a recompile is quite quick. If the definition of an object used throughout the code is changed, build times will approach that of the initial build.

Compile speed aside, the compiler has numerous bugs in it. I have found a bug in the way virtual functions are called. The following code snippet illustrates the bug.

     virtual int sockinetbuf::bind (sockAddr& sa)
          return sockbuf::bind (sa);
     int sockinetbuf::bind (unsigned long addr, int port_no)
     // address and portno are in host byte order
          sockinetaddr sa (addr, port_no);
          return sockbuf::bind (sa); // problem line

If the problem line called the virtual function bind(sa) instead of sockbuf::bind(sa), the code would generate an access violation.

After working around this problem, I found another problem where it appears that the this pointer is changing across function calls or is getting corrupted. I have not spent any time to determine the exact cause of the problem.

The visual builder, shown in figure 6, is pretty much the same as it was in previous versions of VAC++. It is better integrated with the IDE than in the past, but still feels somewhat separate from the IDE. The visual builder is considerably different from other products on the market, and one of the most powerful models available.

Figure 6. The Visual Builder


The IDE in VAC++ 4.0 is a great improvement over past releases. The incremental compiler, although slow on the first pass, is quick when compiling minor changes. The downside is that the compiler has bugs. I wouldn't recommend porting a large existing application to the compiler until another fix pack has been released for it. As always, the more power your computer has, the better. More memory and a faster CPU are more important than a faster hard drive. Previous releases of VAC++ have been hard- drive bound.

Porting existing code to VAC++ 4.0 is hampered by several factors. The C++ language specification has changed. This can require some tweaking of template classes. The compiler design has dramatically been altered. Finally, the IBM Open Class Libraries have deprecated numerous functions and classes.

Overall I like the product but have reservations about recommending it until another fix pack is released, especially for working with large existing code bases.