VAC++ NT vs. OS/2

Written by Gordon Zeglinski

Introduction
Several months ago, IBM released VisualAge C++ (VAC++) Version 3.5 for Windows. This extends the VisualAge product line to allow the developer to write applications (via the Open Class Library) that run on NT and Win95, in addition to OS/2 and AIX. After months of using this product, we bring you the review of the package.

By no means is this compiler light on the HD space. A complete install needs nearly 400 megs of HD space (more if you install the Open Class Library source code). This is more space than used by the OS/2 version of the compiler. However, it should be noted that the Windows version has more features.

Before reviewing this package, I got to talk to several of the "high ups" on the VAC++ team. It was great to talk to people who are interested in hearing how to improve their products and make their customers' jobs easier. Their commitment to producing a quality product was both evident by what they had to say and by the freely available fixes frequently released.

Compiler
New to the compiler is support for C++ Runtime Type Identification. This allows safe type casting at runtime, plus other features useful when developing complex class hierarchies. In addition, the compiler has new optimizations and code generation options.

Comparing the size or speed of executables across 2 different operating systems would be inappropriate. Even comparing the compilation times would be pointless because of the difference in file caching, etc. across operating systems. Instead, we compare the ease of programming between the 2 compilers. In recent months, I've become a big fan of the container library (part of the Open Class Library). One of my current projects utilizes the container classes heavily and is simultaneously being built under NT and OS/2. While making some code changes under NT, I got a slew of mangled function names not being found spewed forth during the linking. After trying to figure out what was going on, I rebooted to OS/2 and tried compiling the same code. The OS/2 compiler complained about missing template functions. Sure enough, I forgot to define a template function needed by the container library. Outside of this annoyance, no major problems where encountered.

When writing code meant to compile under OS/2 and Win32, care must be taken to avoid using features found exclusively in version 3.5 of the compiler. These features are documented in the online help. Once the OS/2 version is upgraded, this won't be a problem.

For those who need to link in 3rd party DLLs, the compiler is capable of hooking into DLLs that use the MSC cdecl calling convention, as well as those that use the standard windows calling convention. It can get a little tricky sometimes if the 3rd party header files aren't designed for use on compilers other than MSC. But with a little work, they can be made usable. Alternatively, the default compiler calling convention can be changed to match that of what the DLL expects.

Development Environment


Because of the underlying differences in the two operating systems, the workframe has changed substantially. Although the look is similar to the OS/2 version, the underlying design is different. The figure above, shows the Win32 workframe. Below, we see the compiler option dialog window.



Overall, the workframe is similar enough to the OS/2 workframe so that little effort is needed to get used to it. The biggest difference is that messages from the compiler and nmake appear in the editor and NOT in the workframe window. Personally I hate this change. A major problem in this version, is the editor. For some reason, the default configuration of the editor causes all files to be edited in the same window. Also, the editor occasionally crashes. When it does, all editor windows vanish.

Even though the overall package is composed of several individual components, they are integrated well. Any tool invoked from the workframe will allow the project to be made, rebuilt, or launch another tool. Outside of bugs in the editor, the IDE is quite good.

Debugger
The debugger is a "less pretty" but equally functional version of the debugger included in VAC++ 3.0 for OS/2. Below, we have the "command center" for the debugger.



From here, the programmer can examine the properties of the active threads, or open source windows for the various modules that make up an exe or DLL. The source window shown below, provides an easy to use interface to setting break points, examining variables, the call stack and other useful functions.



The call stack window shows the currently active functions on the stack, what module defines the function, how much stack space the function is using, and other configurable options (see below).



There are several types of variable monitors available. One of the more useful ones is the Local Variable monitor, shown below. This monitor displays the variables active in the current scope for a thread.



Overall, the debugger is easy to use and very powerful. Especially nice is the async-message queue in NT. This makes debugging GUI applications much easier than in OS/2.

Browser
The browser allows the developer to quickly locate and view object definitions. Personally, the only time I use a browser is to examine class hierarchies I did not write, which is rare.

There are 2 basic types of windows in the browsers. The list and the graph windows. Show below, is a list window showing the members of the class MIMEType and a list window showing all the objects defined in the file mimetype.hpp.





The graph windows display hierarchical type information. Show below is the hierarchy for the classes derived from ios. I found this information useful when porting the Socket class hierarchy to NT.



Overall, the browser is easy to use and well thought out.

Profiler
One of my favorite tools in the VAC++ family is the profiler. Although it's not used nearly as much as the workframe, editor, or debugger, it can be an invaluable tool when trying to find performance losses in large applications. New to version 3.5 is the ability to view information by class in addition to by function.

Once a trace file is created, the data may be viewed in one of several different formats. The following window is displayed showing the current display styles.



The dynamic call graph (shown below) is one of my favourite displays. From this display, one can quickly see which object or function is using up the most cpu time, and how many times a function is called. Using this information, I was once able to quickly track down a logic bug in a program that resulted in substantial performance losses.



The compiler inserts hooks at the start of each function that allow the profiler to accurately determine the runtime information. This differs substantially from other profilers which use a time interval to "check up" on the application. This approach simply gives statistical information about the application.

Visual Builder
The visual builder is unlike any other GUI builder. It is based around the concept of parts. When designing components of an application, the programmer is creating parts. Parts link to other parts. These links represent how the parts interact. Parts can be either visual parts as shown below, or non-visual parts. Non-visual parts include such things as the various container classes, string classes, and the like.



There are two ways to add parts to the Visual Builder. Visual parts are added by creating them with the builder. Additionally, new parts can be added by creating a C++ class for the part, and then describing the interface to the part using the specified syntax. The parts concept truly makes reusable code possible.

Open Class Library
The open class library is the heart of the package. The Visual Builder generates code that uses this library. Also, this library provides the OS abstraction needed to write portable code. It provides classes to do OLE, the various GUI components, collection classes, threads, semaphores, multi-media output and other services. The downside to using these classes is speed and size of the executable. As with any OOP library that abstracts the OS from the application, the resulting programs are a bit larger and slower than if the code was written in an OS specific manner. Previously, we have created simple applications using the open class library. The reader is referred to any of these articles for more info on how the library works.

Documentation
Documentation is available in either a hardcopy/softcopy combination, or softcopy alone. The softcopy documentation is in the .inf format OS/2 users are used to. Included is a win32 version of "view" (the .inf viewer). The .inf format is certainly a lot better than the .hlp format of the win32 reference shipped with the licensed windows SDK components. Overall the documentation is on par with that shipped with VAC++ 3.0. Differences between 3.5 and 3.0 are clearly documented. Overall, the documentation is well written and easy to use.

Summary
In general, the initial release of this package is much better than the initial release of VAC++ 3.0 for OS/2. Developers familiar with VAC++ for OS/2 will quickly become comfortable with this product. Without a doubt, this is the "compiler family" for those who are serious about doing cross-platform development.

Note: I used the term compiler family because compilers for each OS are sold separately.