Moving Up to VisualAge C++ From CSet++
The VisualAge C++ for OS/2 product offers a number of enhancements over C Set++ that can speed up application development and improve the performance of your final product. In addition to providing faster link times, VisualAge C++ integrates object-oriented management, and it comes with its own graphics program build environment.
Moving up to VisualAge C++ is simple, but there are a number of small details to be aware of when you first migrate your existing C Set++ applications. This article identifies the most important differences affecting migration. If you consider these changes and use a little care, the operation is fairly simple and straightforward.
You can divide the essential considerations for migrating from one compiler to another into these major areas compile and link behavior, runtime changes, and required FixPaks. We will discuss each of these in turn.
Compile and Link Behavior
VisualAge C++ introduced a number of new features through compile options; there are several new options and some older options have been retired. This means that you will have to make minor changes to your make files if you want to take advantage of the new features or if you were using the now obsolete options. Here are the details:
- The old /K compile warning flags have been discontinued. These were a hangover from the C Set/2 compiler, and were supplemented in C Set++ by the /Wgrp compile options. In VisualAge C++ the /Wgrp options are the only warning control flags.
- If you have a policy of warning free builds, you need to know that VisualAge C++ changed the default setting of some of the /Wgrp flags /Wpro ( prototype checks), /Wret (return code checks), and /Wcnd (conditional expression check) are now set to on by default. These changes were made to encourage stronger type checking, easier reuse, and portability.
- VisualAge C++ now provides an optimization option for size (/Oc). If you have problems with EXE size, this option may help; it disables some of the more space-hogging optimizations.
- You cannot link objects compiled with the /Ge- option into an EXE. This just happened to work in C Set++, but VisualAge C++ does not allow it EXEs built this way have the annoying habit of terminating before getting into main(). If you have an EXE that terminates during initialization, examine the linker MAP file and look for __dllentry. If it is there, recompile using /Ge+ or / Ge for all source files.
Compiler Standards Compliance
The C compiler in VisualAge C++ has been brought up to the level of the latest IBM C compilers. This will have only minor effects for most people, but you should be aware of the following differences:
- The C compiler message numbers were changed. This will affect you if you filter the error output from the compiler.
- You can no longer redefine the ANSI standard precompiler variables, such as __STDC__. This may cause a problem with code that requires __STDC__ to be defined and yet also makes use of extended library functions. A clean way around this problem is to compile with /Sa /D__EXTENDED__.
New Compiler Features
The implementation of precompiled headers is changed in VisualAge C++. This change can result in improved compile times if your application is structured to take advantage of them, but it is unlikely that a migrated application will be able to do this. Your best bet is to turn off the /Fi and /Si flags until you restructure some code. Likewise, you can delete all old precompiled header files contained in directories named CSET2PRE. Precompiled headers are now placed by default in the build directory. They are contained in a single file with the default name of csetcpp.pch.
There is a new pragma that may help you if you have your own libraries #pragma library() enables you to put default library references into your object modules so that you do not have to specify the libraries in the link step VisualAge C++ takes advantage of this to automatically link in its class libraries. Take a look at \IBMCPP\INCLUDE\IBASE.HPP to see how it is done.
VisualAge C++ comes with a new linker, ILINK.EXE. You must use this linker with the VisualAge C++ libraries because they are in a new format that is incompatible with LINK386. ILINK will handle the old library format and can be used with C Set++. It can be 3 to 5 times faster than LINK386. If you link your application the recommended way, with ICC, you will probably have no migration problems. If you explicitly link with LINK386, you will need to change your build process.
These are the new linker features and functions that you need to be aware of for migration.
- ILINK supports both a new free-format command line and the old LINK386 fixed-format command line. To use a fixed-format command line, the first parameter on the line must be /NOFREE.
- ILINK supports the new smart linking function. This function allows the linker to only link in a single function from an object module if that is all that is required. The object module must have been compiled with /Gl, and you must link with the /OPTFUNC linker option.
- There is a companion library utility to ILINK named ILIB.EXE This utility is similar to the old LIB.EXE, except that it creates the new library format. Both ILINK and ILIB will accept the old library format. If you need to create the old library format, the old LIB.EXE is provided under the name LIBV2R1.EXE.
- In C Set++, instantiating C++ templates wherever they were used was possible, but tended to bloat your executables. In VisualAge C++, the linker is smart enough to throw away all but one copy of the template code, making this a viable way to implement templates. Look up Using Templates in C++ Programs in the C/C++ Programming Guide online document for guidance. Once VisualAge C++ is installed, this document is available in the VisualAge C++ Information folder in the main VisualAge C++ folder.
- You can link objects compiled with C Set++ to objects compiled with VisualAge C++ under some conditions. The limitation is that they can only use one run-time library, either from Version 2 or from Version 3. Make sure you compile with the appropriate library headers for the library you intend to use! There are some options that will make this easier. The VisualAge C++ compiler has the /Gk switch, which suppresses the Version 3 default library records and puts the Version 2 library records in their place. You can also use the extended /NOD linker switch If the switch is in the form /NOD dde4mbs, it suppresses the default inclusion of the Version 2 multithreaded library.
- C Set++ sometimes had problems with the sheer size of the debug information in executables. We know of cases where an executable with debug information exceeded 50MB VisualAge C++ gives you a choice on the amount of debug information provided. You can compile with the /Ti option, as in C Set++, and get full debug information. You can also compile with the new /Tn option and get reduced debug information. The /Tn option gives only the capability to look at your code in the debugger and can reduce the debug information size by a factor of 3. The trade-off is that you cannot look at variable values if you have compiled with the /Tn option. VisualAge C++ also provides a linker option (/DBGPACK) to pack the debug information, making it smaller. This option can also reduce the size of your debug executable.
- pragma checkout has been replaced by #pragma info to control the generation of informational messages.
The run-time libraries in VisualAge C++ were renamed to prevent name collisions if it is installed on the same machine with C Set++. The naming convention is given in the Frequently Asked Questions online document.
Also, the run-time library locales were completely reimplemented in VisualAge C++ to provide full POSIX locale support. This support is significantly more extensive than that provided in C Set++ and may affect the files that you ship with your application. If your application uses locales, you should read the chapters on locales in the C/C++ Programming Guide online document.
IBM Open Class Library
All the VisualAge C++ class libraries are now called the IBM Open Class Library. The documentation has been integrated into two manuals a user's guide and a library reference.
As a result of this consolidation, the Open Class Library LIBs and DLLs have been renamed following our new naming convention. However, you really don't need to worry as the Open Class Library uses the new compiler #pragma lib to reference the correct LIBs depending on your compiler options.
The Open Class Library now includes these new features:
- Database access classes
- Multimedia classes
- 2-D graphics
- Mouse handling
- Flyover help
- String parsing
- Animated buttons
- Support for the notification framework used by the Visual Builder
For more information about these new features, see the online documentation provided in the Open Class Library User's Guide and the Open Class Library Reference.
One gotcha to look out for is that the Open Class Library requires that programs be linked with the multithread libraries. Therefore, you must compile with the /Gm+ switch. If you forget, then you will get an unresolved reference to _errno at link time.
The algorithm used by the memory manager in C Set++ was heavily biased toward applications that were not memory constrained (i.e., that did not cause much OS/2 swap activity). To remove this bias, a new algorithm was selected for VisualAge C++. The new algorithm requires less space. Where C Set++ took the requested size, added 16 bytes, and then rounded up to the next power of 2n to get the actual storage required, VisualAge C++ uses one of the following two algorithms.
- Non-debug allocations Add 8 bytes to the requested size, and round up to the next multiple of 16
- Debug allocations Add 16 bytes to the requested size, and round up to the next multiple of 16
The new algorithm results in a much smaller application memory footprint Of course, there is a cost - VisualAge C++ is much less tolerant of improper heap use than C Set++ was. The following are common cases where C Set++ either ignored the error or leaked memory quietly, but where VisualAge C++ traps.
- Freeing a memory block twice
- Freeing memory that was allocated by a different copy of the run time This commonly occurs when memory is allocated by a DLL and freed by the EXE C Set++ allowed the two to be linked to different copies of the run time VisualAge C++ does not. There is one non-obvious case where this can happen the C++ new and delete operators Because of the way that virtual objects have to be implemented, the memory is freed not by the delete operator itself, but by the object destructor If the destructor is linked to a different library, you can get into problems.
- Using the delete operator to free memory allocated by new VisualAge C ++ requires that you use delete
- Freeing an arbitrary memory pointer C Set++ usually ignored this VisualAge C++ will not
Because of the new memory management algorithm, you may run into problems interfacing to 16-bit code. Although it wasn't guaranteed, memory allocated by C Set++ was always tiled. This is no longer true for VisualAge C++. If you are interfacing to 16-bit code, you must use the /Gt compile option.
Debug memory management is significantly more robust in VisualAge C++. It has also been expanded to allow debug and tiled memory, something that was not possible in C Set++ (i.e., the compile option combination /Gt /Tm is now valid).
Applying VAC++ FixPaks
As usual with all large products, there are always problems to be fixed after the delivery of the product. We fix them using FixPaks, which you can download from several sources as well as finding them on the DevCon OS/2 CDs. It is always wise to update your VisualAge C++ installation to incorporate the latest fixes FixPaks for VisualAge C++ are divided into components as follows:
|Component||File to Download|
|Compiler, Linker, Librarian||CTC30n.ZIP|
|Open Class Libraries||CTO30n.ZIP|
|Visual Builder and Data Access Class Builder||CTV30n.ZIP|
|Documentation and Samples||CTD30n.ZIP|
VisualAge C++ for OS/2 FixPaks follow this naming scheme CTx30d where x represents the component, and d represents the CSD level.
The FixPaks are cumulative. For example, support for DB2/2 Version 2.1 is provided by the CTV301 FixPak and is included in CTV302, CTV303, and so forth. FixPaks are available from many sources, including:
- The Developer Connection CDs
- Internet ftp://ftp.software.ibm.com/ps/products/visualagecpp/fixes/v30os2/english-us
- Each FixPak has a subdirectory containing 3 files other zip file to get (includes the 2 other files).
- a listing file describing the FixPak
- README TXT file with instructions for applying the FixPak
- COMPUSERVE forums GO VACPP
To apply the fixes, unzip each ZIP file into an empty directory using the -d switch to expand subdirectories. Then follow the instructions in the README.TXT (or other obviously named text file).
You should apply the fixes in the following order:
While there are many changes and improvements in VisualAge C++ over C Set++, most of us have found making the transition to be quick and easy. In fact, at the IBM Software Solution Toronto Lab, we have migrated many of our large program products without a hitch. The faster link times alone have made it worthwhile. Once migrated, you too can enjoy the benefits. Upgrade now!
Reprint Courtesy of International Business Machines Corporation, © International Business Machines Corporation