VisualAge C++ 4.0 Review

By Douglas Clark

There are certain oxymoron's that are universally known and instantly understood: free lunch, army intelligence, and C++ RAD. Everyone knows there is no such thing as a free lunch, every private in the army can tell you about army intelligence, and all programmers know that C++ and Rapid Application Development (RAD) are mutually exclusive. And yet IBM's VisualAge C++ version 4.0 (VAC4) is exactly that. In fact the distinguishing characteristic of this latest version of VisualAge C++ is the RADness of the product.

RAD languages are usually wimpy 98 pound languages like Basic, Pascal, and Rexx. Up to now C++ has been much too powerful, complex and hairy-chested for RAD - heck the primer for C++ (referenced below) is more than 1100 pages with no pictures or screen shots. And big hairy-chested languages require big hairy-chested development environments, which conspires against RADness. But the new integrated development environment (IDE) combined with IBM's Open Class Library (OCL) and quick recompile times make for an excellent RAD. By way of comparison, the speed at which you can develop a simple non-GUI program in VAC4 is close to what it would take in Rexx.

When you program in Sibyl or Delphi (or Rexx) you don't have to worry about linking object files, prototyping functions, or bracketing header files with preprocessor statements to prevent multiple inclusion. You just slam in your code and click on the Run button - you concentrate on writing code instead of compiling. That is exactly what you do with VAC4. This version frees you from most of the tedium of writing C++ code.

But RAD also means quick turn around from when you enter the code until when you execute the program. With Delphi, Borland achieved quick turn around times in the "code - run - code" cycle by having a blazingly fast compiler; in VAC4 IBM achieves quick turn around times by only compiling the portion of code that changes instead of the entire source file that code was contained in.

As icing on the cake, once you have built your application in OS/2, you can copy the source code to NT, recompile, and have a working cross platform application - sort of like Java eh? If you actually have to develop on nasty old Windows, the tools and environment are the same and work the same, minimizing the pain of switching platforms.

In order to accomplish all this, a completely new, completely different development environment was created. For the most part different is good - the benefits are enormous. But all is not roses - transitioning to the new environment with large amounts of existing C++ can be extremely painful.

While this is an OS/2 magazine I will also cover the Windows version when appropriate, since many OS/2 developers need to leverage Windows to help provide a profit out of development costs or to help fit in with today's IT world. I have been using VAC4 daily for a little over 2 years now - this article is a review of the product and my experience with using it in my day to day job.

What's in the Box
Included in the box are 4 compilers: version 4.0 for OS/2 and Windows NT, and version 3.6 for OS/2 and Windows NT. Two different versions of compilers are included for three reasons:
 * 1) Version 3.6 uses make files for building projects and provides the traditional build environment. Version 4.0 uses a new configuration file and provides the RAD environment.
 * 2) Version 4.0 compiles code that conforms to the final C++ standard approved in 1998 and code that conforms to the old ANSI draft standard of 1992. Version 3.6 only handles 1992 level code.
 * 3) Version 3.6 debugs C code and generally provides better C support. Version 4.0 will compile C code and include debugging information in the object/executables but you use the debugger from version 3.6 to debug C code.

Version 4.0 also includes:
 * The standard C++ library, including the STL. The library is licensed from Dinkum.
 * The IBM Open Class Library (OCL), which incorporates most of the functionality of the standard C++ library, plus classes which encapsulate the GUI parts of OS/2 and Windows NT.
 * The Visual Builder - a tool where you can visually build applications by placing parts on a palette and connecting the parts together. The parts can be either visual, i.e. GUI parts or non-visual parts.
 * Data Access Builder - a tool for handling database access. Data Access is accomplished by building C++ classes for an SQL cursor or table which you then use to access a database.
 * LPEX - a programmers editor.
 * IDE - which provides an integrated environment for working with the external tools - the function of the previous version's Work Frame - and has some built in internal tools which cannot be accessed outside of the IDE.
 * A subset of the OS/2 toolkit on OS/2, or the Windows SDK on WinNT.
 * The Integrated Resource Editor, tool for creating and editing resources.
 * Extensive on-line Help, with some sections of that help extracted into PDF format to help you get started.
 * The C++ Programming Language Third Edition by Bjarne Stroustrup as an on-line only PDF document.
 * There is supposed to be a performance analyzer for determining which sections of code get executed how often, but I could not get it to work in OS/2.

The version 3.6 compiler includes You can install both compilers on the same machine; if you are planning on doing much C coding then you should install both.
 * The IBM Open Class Library.
 * The debugger.

Installing the Beast
Installing VAC4 can range from a trouble free walk in the park to something akin to being in the first wave landing on Omaha beach. I have installed the OS/2 and NT versions on multiple machines with varying, mostly good, results. However there are some really nasty horror stories in the news groups about installs going awry. In my experience installation problems seem to revolve around four issues:
 * 1) VAC4 is very picky about hardware. It will complain or not run on a machine that is seemly running everything else just fine. I've run into this more with OS/2 than with Windows.
 * 2) You need to get TCP/IP setup correctly before the install; otherwise some parts of the help system may not work.
 * 3) DB2, VAC4 and VAC3.6 all use the same help system, although different versions. If DB2 and VAC are to co-exist on the same machine, with both help systems working, you must follow some extra steps for installing which are outlined in the DB2 installation readme file.
 * 4) The install program for OS/2, Feature Install is terrible. Just getting Feature Install itself to work can sometimes be a challenge.

If you are going to install both compilers on a single machine, IBM recommends installing 3.6 first; I have installed them in either order and it doesn't seem to matter.

VAC is a resource pig. IBM says the minimum amount required RAM is 96MB, the recommended amount is 128MB; 256MB is even better. I have used the product in OS/2 on a Pentium Pro 160 and in WinNT on a Pentium Pro 200. If you are very patient it can work. My regular machines are Pentium II 450 for OS/2 and AMD K3 450 for WinNT; both are snappy and work fine.

Get TCP/IP set up and working first. If you change your IP address after installing VAC the help search engine may not start. A work-around is documented in a DB2 file DB2_RELEASE.TXT, but for some reason is not documented in VAC.

The Performance Analyzer (which doesn't appear to work in OS/2) and the 3D Inheritance graphing tool are packaged as something called Tech Preview. You have to specifically select it to get it to install.

OS/2 Installation Specifics
The OS/2 version seems to be very picky about hardware. On various SuperMicro motherboards/Matrox Millennium video cards combinations, VAC will not run with Matrox drivers above version 2.23; neither will Sibyl, although Sibyl will run with the latest Matrox driver 2.54. Switching to SciTech Display Doctor video drivers fixed the problem, allowing both VAC4 and Sibyl to run on the same machine. Either IBM's version or Scitech's version will work.

After I first installed VAC on OS/2 Warp 4 with a SuperMicro motherboard I had random segmentation violations while compiling. This problem turned out to be memory that was incompatible with the motherboard, although I did not notice problems with other applications. Switching memory fixed the problem.

Software wise, VAC requires fixpak 8 for Warp version 4, which is included on the CD. It runs on Warp Server for e-business (WSeb) with no fixpaks.

The OS/2 version uses Feature Install as the install program. Feature Install is a Netscape plug-in that interfaces to Java and uses the browser as its user interface. It is VERY slow and problematic. If you don't already have Feature Install installed then you must run the Install Installer option when running Install before you install VAC. (Got that?) Why IBM would use Feature Install when it already has a very nice, very reliable install program that has been around for years is beyond me.

If you install the Tech Preview after installing the rest of the package some of the icons in the VAC folder will probably go away. Therefore it is best to install the Tech Preview at the same time as you are installing the rest of the package. You must select the check box for it during the install process, as it is not installed by default. As best I can tell there is no program to recreate desktop icons in this version, as there was in the last version.

When you install the Tech Preview you will have two icons in the VAC4 folder for the IDE: one that incorporates the IDE enhancements and the regular one. You click on the IDE Tech Preview icon for those extras to appear in the IDE. If you get an error saying "An error occurred when parsing D:\IBMCPP40\ETC\user.cfg" then


 * 1) Rename the existing file user.cfg in your D:\IBMCPP40\ETC directory, where D:\IBMCPP40 is the drive and directory where VAC4 is installed.
 * 2) Unzip the contents of USERCFG.ZIP into the D:\IBMCPP40\ETC directory.

This will not fix the performance analyser but it will allow the 3D Inheritance graphing tool to work.

Once you get VAC installed there is one fix pack for version 4 and two fix packs for version 3.6 that you need to install which take care of a number of bugs. The fix pack installation also uses Feature Install. Did I mention that Feature Install really stinks?

WinNT Installation Specifics
The Windows version will only run on NT, although the code generated can be run on 95/98.

NT needs Service pack 3 installed. The boot drive must be running NTFS; if the boot drive is running FAT the help system probably will not run at all, regardless of the file system VAC is installed on.

The installation program is run by InstallShield and is a pretty typical for InstallShield. You must use a Custom Install if you intend to install the Tech Preview and get the Performance Analyzer and 3D Inheritance graphing tool.

After you get VAC installed there are 3 fix packs that currently exist for version 4 and 2 fix packs for version 3.6.

Making a Project
A project consists of a configuration file, source file(s), and after the first build, a code store. There is usually one project per target (the thing you are building) although a single project can produce multiple targets. You can create a new project by creating a new configuration file, or you can use Smart Guides, a.k.a. wizards, to help create a new project.

The configuration file replaces the function of a make file, designating


 * what you want to build - the target,
 * the source files that make up the target,
 * and optionally, any processing options to use for the build.

The configuration file is a normal text file that uses (to me) a much simpler syntax than make files. The syntax resembles C/C++, e.g. blocks defined by curly braces, comments are either /* */ or //, etc. Once you have created the configuration file it can be modified in the editor or via the IDE in the Configuration section. I usually edit the configuration file directly rather than use the IDE configuration tools because it is faster, and the structure of the file is so simple it is easy to do. Likewise when I create new projects I usually just copy an existing configuration file to a new directory and change the target and source statements. The configuration file below creates the executable unencrypt.exe from three source files: crypto.hpp, crypto.cpp and unencrypt.cpp and includes the header file ITIME.HPP from the Open Class Library ITIME class. option ProjectOptions = gen(rtti, yes),macros(global,yes) {  option  link(linkwithmultithreadlib), link(linkwithsharedlib), incl(searchpath, .), lang(nokeyword, bool), lang(nokeyword, true), lang(nokeyword, false), define(IC_LANG_BOOL, 0), define(_X86_), define(IVB_IMPORT, _Import), link(pmtype, VIO) {     target unencrypt.exe; {        source ITIME.HPP source ..\\crypto\\crypto.HPP source ..\\crypto\\crypto.CPP source unencrypt.CPP }  } } The target in the configuration file, or more specifically the extension of the file name, determines the type of object built. If the target file name has an extension of .EXE then an executable is built; an extension of .DLL will create a DLL file and an associated LIB file for static linking. It couldn't get much easier. The configuration file below builds the DLL npipe.dll from the source files namedpipe.hpp and namedpipe.cpp. Since the OCL classes IString and IException are used, those two header files are also included as source files. Notice the statement link(exportAll); this exports all the stuff being built in the DLL so that it will be visible to any program that uses the DLL. Alternately I could have specified _Export directives for each object in the DLL that I wanted visible, but this is a whole lot easier. option ProjectOptions = gen(rtti, yes),macros(global,yes) { option link(linkwithmultithreadlib), link(linkwithsharedlib), incl(searchpath, .), lang(nokeyword, bool), lang(nokeyword, true), lang(nokeyword, false), define(IC_LANG_BOOL, 0), define(_X86_), define(IVB_IMPORT, _Import), link(pmtype, VIO) ,link(exportAll) {     target nPipe.dll {        source istring.HPP source iexcept.HPP source namedPipe.HPP source namedPipe.CPP }  } } The configuration file recognizes variables, conditional statements like IF and FOR, and runs external programs. It can be a very powerful and flexible tool.

During each build, VAC4 builds and maintains a database of the project called a code store. The code store tracks the source objects that make up a project, files, classes, functions, etc. This is used by the IDE for editing, browsing and debugging the project, and it is used for what IBM calls incremental builds. The code store is a single disk file which can grow quite large. Occasionally the code store becomes corrupt and has to be rebuilt. This is done either by deleting the code store file on the hard drive and doing a build, or by using a Clean Code Store menu option in the IDE. Normally the corruption in the code store is obvious - you get a message in the IDE saying its corrupt. But sometimes I have seen code store problems appear in non-corrupt code stores. These manifest themselves as builds that fail for reasons that cannot be true, e.g. the link fails because VAC4 cannot find a class or method that exists in a linked-in DLL, etc. These also are fixed by deleting the code store and rebuilding. Both of these code store problems happen occasionally - working with 15 to 20 small to medium size projects 4 to 6 hours a day I will see a corrupt code store about once every 45 days or so.

Incremental building means only updating the part of the code which changes from one build to the next. A traditional make file type compiler does this at the source file level; when a source file changes according to the file timestamp it is recompiled and anything that is affected by that file is also updated. In VAC4 this doesn't happen at the file level - it happens at the function level. If only one function in a large source file is changed, only that function is recompiled and relinked. This results in some very quick rebuild times, especially on slow machines or large projects.

Projects can be migrated from OS/2 to Windows NT by copying the configuration file and source files from one machine to another and rebuilding. The code store is not compatible between operating systems. And projects can be migrated from Windows NT to OS/2 the same way - including those projects which have Visual Builder parts, which was not true in version 3.0/3.5.

Migrating projects from version 3/3.5 to version 4 is not as easy. Many of the problems revolve around converting the make file for a project into a working configuration file. While there is a conversion utility to assist migrating make files to configuration files, my experience has been that you seem to still end up with compile errors, mostly related to #include problems. This manifests itself as reports of the same object appearing twice. Once you get past getting the configuration file correct, you may have issues related to the C++ language standard changing from the previous version. The pain you experience migrating a project from the previous version will depend on how complex the project is and features of the language you have utilized.

The IDE
The IDE ties together the various tools that make up VAC4. Where in the previous OS/2 version the Work Frame component listed source files, invoked tools and handled messages from the tools, in this version that is all handled by the IDE.

The IDE is organized by tabs which are called sections, and buttons which navigate you to a page, which may nor may not be subdivided into separate panes. The tabs and buttons are equivalent to major and minor tabs in an OS/2 notebook control except that both are arranged along the top of the screen. The tabs/buttons take you to a page where you work in the IDE. There are 4 major tabs but most of your time in the IDE will be spent in one tab, the Project section.

On most pages the panes are linked together so that selecting something in one pane effects what is displayed in the other pane(s), just like selecting a directory in the left window of file manager changes the files displayed in the right window. The figure below shows the Overview page in the Project section. The upper left pane displays the classes in the project, the upper right pane displays the source files that make up the project, the lower pane is the editor. Selecting a class in the upper left pane causes the editor to display the source that defines that class. Selecting a source file in the upper right pane causes the editor to display that source file. You will notice there are symbols next to the items in the two lists. The symbol indicates what type of object is in the list, for example in the file list on the right the S indicates a source file listed in the configuration file, the I indicates a file that was #included in a source file, and the ConFigFile indicates the file is the configuration file for this project; the F symbol in the Declarations list indicates the object is a function - in this case a class method. With this page you can work on your project at the object level or at the source file level.



You can change what is shown in each pane - that is the view, filter the objects shown in a view, change which panes are linked together and how they are linked, create new filters for filtering objects, new tabs and pages for the tab. In short, the IDE can be extensively customized, and is extremely powerful. We will look at some views and pages below.

The figure is the declarations view, which lists all the objects declared in the project. This view appears on various pages in the IDE. Each object in the list has a symbol to the left of it so show what type of object it is. In the figure below you can see some functions, the class named statement, functions (methods) and variables and friend classes of that class.



The line with the flash-light is for typing search strings to find objects in the list. Clicking on a item in the list - class, method, variable, function, etc. - will update any other pane on the same page linked to this view. For instance in the Find Uses page shown below, the Uses pane and the editor are both updated to display the item selected in the Declarations pane.

Many panes/views have filters for restricting what is shown in the view. Clicking on the icon in the upper left of the window opens a menu where you can select a filter to apply to the view; the red dot in the icon indicates that a filter that excludes some items from the view is in effect.



The Find Uses page provides a way to quickly find where an object is used. Clicking on an object in the upper left pane updates the upper right pane to show all instances where the object is used and updates the editor in the lower pane to show source where the object is declared. Clicking on a item in the uses list in the upper right pane updates the editor to show the source where the object is used. In this figure the moveTo function selected appears in 4 locations as shown in the upper right pane. The source code for the second of those uses is shown in the bottom editor.



The Class Hierarchy page graphs class inheritance for the project. Right clicking on a class displays a pop-up menu which you can use to select the class declaration view (shown a couple of figures above) where you can edit a specific method, etc.



The Perspective page shows a 3D inheritance graph (part of the Tech Preview) in the left pane, the 2D inheritance in the upper right pane, and the class declaration in the lower right view. You can edit a method or variable, etc. by right clicking on the method in the lower right pane and selecting Floating Pane from the pop-up menu; this will open the editor as a separate window that floats above the IDE. The 3D graph is sometimes helpful tracing multiple inheritance links in classes.



The Search page provides a grep function for searching for text strings in the source files that make up the project. It is divided into three panes, you enter a search string in the upper pane and click on the flashlight. The places where the string are found are displayed in the middle pane, and the editor in the bottom pane shows the source for the selected object from the middle pane. This page can also be used as a grep that searches directory structures instead of just source files in the project.



Debugging is handled in the IDE on the Debug page. You don't need any special settings or options turned on to debug, the debugger uses the information from the code store. This means that the debugging information is not in the compiled code you send out, so you don't have to take it out before you send your code out. C code however is not stored in the code store so you must use the debugger that is part of the 3.6 version compiler to debug C code. The debugger has the normal functions and outputs that you would expect.



When you step through a program the source code is displayed in the editor, the bottom left pane in the figure below. Since you are viewing the source in the editor you can change the source, or do anything else you can do in the editor, while the program is being debugged.



When I first started using the IDE I was somewhat intimidated by the size and complexity of the thing. But the IDE is somewhat like C++ itself in that you do not have to use all the features when you start; you use what you need. In fact you may never use some of the features (of either the IDE or C++,) but it is nice to know that they are there. With the range of configuration possible and the power of the features in the IDE it is unlikely that most programmers will outgrow it.

The Editor
No matter what features any development environment has or the language used, the majority of a programmer's time will be spent in the editor. All other IDEs that I have used, except Work Frame in VAC3.0, have forced me to use their editor. And all of those other editors have not had the power or the feel of the editor I prefer: EPM. VAC4 solves the wimpy editor problem two ways:


 * 1) You can edit the project's source files outside of the IDE, in any external editor, while the IDE is open. By default when the IDE receives focus it checks the timestamps of the project's source files and if a newer version exists you are prompted to load that newer version. You can also setup the IDE to automatically load a source file into any external editor you specify. The downside of this is that it probably screws up IDE's ability to ascertain which functions have changed resulting in the whole source file being rebuilt.
 * 2) The editor provided, LPEX v 4, is basically the successor to EPM. Sort of a EPM++. Almost everything you can do in EPM you can do in LPEX, although you may have to write editor macros to do it.

This is the next version of the editor used in VAC 3/3.5. LPEX is fully configurable using Rexx macros that issue editor commands and set editor parameters, just as in EPM. Except that in LPEX the only macro language used is Rexx where EPM uses Rexx, plus its own E language for performance. LPEX has a C API for writing performance sensitive routines. EPM is customized with configuration files that are compiled with ETPM into EPM specific executables; LPEX uses Rexx macros that are loaded up when the editor starts - no compiling.

Most of the customizations you make to LPEX that work in the external environment also work inside the IDE; the exception is that the IDE reserves certain key stroke combinations to itself and these will override any key customization you have specified.

The editor can view and edit the same source file in two different views or windows. Changes that you make in one view show up in the other view. In the IDE you can do this by opening the file in another pane or tab, or by opening a floating pane.



When running the editor externally you do this by using the Split command; the window can be split vertically or horizontally.





The editor can also display and support a line prefix area, like ISPF, where you can enter editor commands. It comes with mappings for ISPF and XEDIT prefix commands, or you can map whatever prefix commands you want to editor commands or macros. The figure below shows a block move of lines 124-129 to a position after line 134. Prefix commands can be handy for accomplishing things that normally require a mouse without taking your hands off the keyboard.



In addition to editing profile macros to customize the editor, the IDE provides a Setting dialog. This gives you an easy way to extensively modify the editor's behaviour.



Visual Builder
The Visual Builder (VB) tool is used to build applications by placing parts on a composition surface and connecting those parts together. Like other visual builders, the parts can be either visual (GUI) or non-visual parts, and like some other builders you can create your own parts which you can reuse for other projects and applications. The big difference between this visual builder and others is in visually connecting the parts, which opens up some powerful possibilities.



Parts in VB are C++ classes and characterized by three logical features: attributes, actions and events. Attributes are logically equivalent to the properties or variables of a class. Actions are the methods or functions of the class. Events are somewhat like messages in Presentation Manager and are used to signal changes in state or happenings of interest in the part/class. Events are passed between classes by a notification framework which takes care of routing the appropriate event to the parts/classes that are interested in that event.

When you connect parts together in VB you are connecting the attributes, actions, or events of one part to the attributes, actions or events of another part. What happens depends on what is connected to what. For instance if you connect an event of one part to the action of another part, every time that event happens, the action (function) of the other part is executed. If you connect the attribute of one part to another part the second part's attribute will be updated every time the first part's attribute changes.

In most visual builders, all the parts (classes) are instantiated in memory when the application starts. With Visual Builder you can control when parts are instantiated by using a factory to create the part you want, giving you control over what gets created when.



The vertical row of icons at the left of the Visual Builder contains categories of parts; when you select an icon/category of parts in the left-most row the icons/parts changes in the right row to what is available in that category. You add a part by dragging from the right row onto the composition surface. Parts that do not appear in one of the categories on the left, e.g. parts you create, can be added via the menus. You can also create parts in such a way that you can add them to categories in the list. Most of the GUI classes in the Open Class Library are available as parts - the part class name begins with IVB instead of I, e.g. the IContainer class is IVBContainer as a VB part.

Once you have placed a part on the composition surface you can browse the features of the part by selecting Browse from the part's pop-up menu. Selecting an attribute, action or event from the lists will update the description at the bottom of the browser.



Most parts also have properties that can be set, from either the pop-up menu or by double clicking on the part. Setting Properties is somewhat like setting class variables to values before run time. Most properties of most parts can also be set at run time by connecting to the attributes and/or actions of the part.



You can add attributes, actions and events to an existing part either by creating a new part based on that part (subclassing) or by adding the attribute, action or event to the part. In order to add features to a part, the part must be distributed with source; OCL parts cannot be added to, but rather must be subclassed - that is you must create a new part based on that OCL part.

Parts can be simple, primitive parts, or they can be composite parts which are made up of other parts. For example, you can build a dialog type window as a part that consists of a number of other parts: frame window, buttons, check boxes etc. That dialog part can then be used in multiple places, realizing one of the promises of object orientated programming.

Visual Builder has three editors:
 * 1) The composition editor, used for composite parts.
 * 2) The Part Interface editor, where you specify attributes, actions and events.
 * 3) The Class editor where you specify what part features (attributes, actions, events) you want prompted and visible, and where you designate external files where you can enter customization code that should not be overwritten with each build. It is in these external files where you flesh out the body of class functions in order to build a part. The Class editor is also where you generate the skeleton code for the class functions you flesh out.

The figure below shows the Part Interface editor from Visual Builder.



Theoretically applications built with the Visual Builder might be slower than those built by hand from the Open Class Library. In practice there probably is not much real difference. The difference in speed is caused by the notification frame work which handles the event passing between parts, and the try/catch blocks built into compiled code by Visual Builder. You can gain some speed by reducing the number of try/catch blocks but at the expense of robustness of the application. And most applications of any complexity will need something that handles the functions of the notification framework.

Parts created in VAC3/VAC3.5 must be migrated before they can be used in VAC4. I had trouble migrating some parts from VAC3 to VAC4 in OS/2. I have not tried to migrate the same troublesome parts in the WinNT version, but with VAC4 it would be possible to migrate the part in WinNT and then copy the part back to OS/2, since parts can be moved from platform to platform in this version. In version 3.0/3.5 you could only move parts from OS/2 to Windows.

The Visual Builder is a powerful tool and the learning curve can be steep when you are trying to do something that is not immediately obvious. Most of the time, whatever it is that you are trying to do can be done - VB is a very well designed and thought out tool. The problem is finding out how to do it. I highly recommend getting a tutorial book (see Other Stuff You May Want below) for getting up to speed quickly on the VB.

Data Access Builder
The Data Access Builder is a tool which converts a SQL select statement, table or view into C++ classes you can use to access the data. The classes uses either ODBC, DB2 CLI or DB2 embedded SQL to access the database. The tool works by you entering a table or view name, or a SQL statement and then selecting the columns (attributes) you want to appear in the resulting classes, along with designating a set of column(s) that describe uniqueness if no primary key exists.

When you press the build button, classes are generated for retrieving rows into an Open Class Library container, updating rows, and deleting rows. Classes are generated for use in the Visual Builder as well as classes for use in normal C++ programming.

The disadvantages to the Data Access Builder are:


 * 1) You must know the table or SQL statement when you are building the application. If you are building an application where you will not know which table you are going against, or the columns from the table you need, you are out of luck.
 * 2) The classes that return the results of a SQL select statement return the entire result set in memory as a container. For large result sets this is probably not what you want.

Libraries
VAC4 comes with two major libraries: the IBM Open Class Library, and the standard C++ library. Unfortunately the two are mostly incompatible, meaning that usually you cannot use one in the same project that you are using the other. There are exceptions and workarounds to this, some of those are described in the supplied documentation on migrating from previous versions of VAC, but generally you should figure on using one library or the other. This problem is not unique to VAC; it has taken so long for C++ to be standardized that almost all compiler vendors developed their own libraries before the standard was finalized. Most compiler vendors have libraries to address operating system specific issues that will never be part of the standard.

The Open Class Library contains most of the functions of the standard library, in many instances with substantially more features than the equivalent standard library class. An example of this is the IString class which has methods for finding words, converting strings to various numeric types, changing specific characters to other characters, etc. none or which are in the standard C++ library. Plus Open Class Library provides a IStringParse class which is used with IString to parse strings into tokens, similar to the Rexx parsers. In fact, the string search and editing functions strongly resemble those in Rexx, giving VAC4 the text processing capabilities of Rexx.

Help & Documentation
The help for VAC4 related items is supplied in compressed HTML format. The help system consists of a mini specialized web server and CGI programs for decompressing and accessing the help files. The help for the tool kit/SDK stuff is supplied in OS/2 Help (INF) or Windows Help format. The help written by IBM is generally very good. The help for the standard C++ library is supplied by Dinkum is terrible. More than terrible, it's hideous. If you don't already know how the standard library works and what is in it, you probably will not figure it out from the documentation.



The samples provided with VAC4 are integrated into the new help - very nice.

The HTML based help is much slower than the old INF based help. Some of this can be mitigated by leaving the browser open. On the positive side, copying examples out of help is now easier, and printing help sections is better from the HTML browser than from View.exe.

What's Missing

 * 1) Printing capabilities. There are no classes for easy printing of GUI elements.
 * 2) Data access is rather weak, especially compared to a Delphi or Visual Basic. There is no report builder for generating reports as part of an application.
 * 3) Direct to SOM is no longer part of VAC4.

Other Stuff You May Want

 * C++ Primer - Third Edition by Stanley B. Lippman and Josée Lajoie. Published by Addison-Wesley. ISBN 0-201-82470-1 (about $45.00). This is an excellent, excellent book on C++ programming. One of the authors is/was in the IBM Compiler group.




 * Power GUI Programming with VisualAge for C++ by Hiroshi Tsuji, Bob Love, William Law and Bruce Olson. Published by John Wiley and Sons. ISBN 0-471-16482-8 (about $55.00). This covers the IBM Open Class Library and is valuable for those using the Visual Builder to create applications as well as coding GUI applications by hand. It has not been updated since version 3 of the library, but is still relevant (though missing the new stuff) for this release.




 * VisualAge for C++ Visual Programmer's Handbook by Dale R. Nilsson and Peter M. Jakab. This book used to be published by Prentice Hall (ISBN 0-13-614322-9) and is no longer in print from them. However it is available from IBM as document number SC09-2489-00 Click on  http://www.elink.ibmlink.ibm.com Then select publications . This book is also orientated to version 3/3.5; while the Visual Builder itself has not changed much, how it is invoked and the way the properties dialogs look has changed, so you will have to make some adjustments. It is well written and I highly recommend this book for those using the Visual Builder.




 * Getting to Know VisualAge C++ Version 4.0, SG24-5489-00. This IBM Redbook is mostly about configuration file building and the build process, along with IDE hints and tips related to that.
 * Building Parts for Fun and Profit S25H-6968-00. This book describes design principles to use when making C++ classes you intended to turn into Visual Builder parts, along with how to do that.
 * PmPrintF32 - this little tool displays messages output during tracing when you have enabled the trace feature of VAC4. It is completely compatible with the original PmPrintF with some enhancements. It is also invaluable for debugging web server CGI programs.
 * PrintQ14.ZIP. I ran across this some time ago on Hobbes, but have not used it yet. It may help in printing from VAC4 applications.
 * ODBC classes. I am working on releasing some ODBC classes for data base access for next month's article on ODBC. These are very loosely designed after Microsoft's data access classes used in Access and Visual Basic and are intended to be very easy to use. Check in next month's issue.

Support and Pricing
IBM very recently announced that VisualAge C++ 4.0 for OS/2 and Windows will not be available from IBM after 4/27/2001. That means that if it is not in stock at a vendor by 4/27/2001 it will be unavailable for purchase. The end of support, such as it is, is scheduled for 9/28/2001. VisualAge C++ for AIX is already at version 5 and supposedly support and development will continue. IBM's official position is: Pricing is approximately: $733.00 for the full retail version; $190.00 for an upgrade version, upgrade being from previous version of VAC or Microsoft C++ or Borland C++; $4.20 for the academic version. All pricing from Mensys, although pricing from Indelible-blue is probably similar.
 * 1) Intel code (meaning anything compiled to run on Intel platforms) is legacy code.
 * 2) Applications should now be developed in Java.
 * 3) Java applications should be developed in Visual Age for Java.
 * 4) All existing C++ (and other compiled) applications should be migrated to Java, at least on the Intel platform.

Fix packs for OS/2 and Windows versions are available at http://www-4.ibm.com/software/ad/vacpp/service/csd.html VAC4 for OS/2 is at fix pack 1, VAC3.6.5 for OS/2 and Win is at fix pack 2, VAC4 for WinNT is at fix pack 3.

The discontinuation of support means there will be no more fix packs. This is probably a bigger concern on Windows than OS/2, since each new version of Windows seems to require major new changes in the SDK and all related tools. OS/2 is stable enough that new versions probably will not break the compiler for a number of years - people are still using VAC3.0 to develop programs that run in WSeB.

Conclusions - Where Do We Go From Here
Developing C++ programs can be very fast in VAC4, or rather as fast as the language allows. It truly is RAD for C++. The combination of the new IDE, language enhancements and Visual Builder make for a stunning application development environment. I find myself now writing small utilities and programs in C++ that I wrote in REXX a few years ago because it is so easy and quick in VAC4.

If you are writing cross-platform compiled programs to run on both OS/2 and Windows there really is no other choice. If you are currently using version 3 or 3.5 this is a worthwhile upgrade, even if you only use it to develop new applications.

C++ is here to stay, despite IBM's lack of commitment to it. VAC4 is currently the ultimate, though not perfect, development environment for C++ on OS/2, and Windows.