A Review Of Symantec C++ 7.0

Symantec’s new release is solid and feature rich

By Jess Holle, Purdue University

About the author

Jess Holle is nearing the completion of his Master's Degree in Mechanical Engineering at Purdue University. He works as a research assistant in the Purdue CADLAB developing CAD/CAM software in C++. His current research efforts center on developing a 3D GD&T (that’s Geometric dimensioning and tolerancing (ala ANSI Y14.5) for you curious types) tolerance scheme in a feature-based design environment.

In May of 1993, Symantec released Symantec C++ 6.0, a C and C++ development environment based on its popular Think C environment. The new modular environment included two compilers: the case-hardened Think C compiler and a native C++ compiler, which was based upon the Zortech compiler Symantec had purchased. Finally there was a real alternative to MPW for C++ development on the Macintosh.

Unfortunately, the 6.0 C++ compiler was less than solid. The bug-fix release, 6.0.1, failed to bring the compiler in line with user expectations. On-line forums, such as comp.sys.mac.programmer on the Usenet, were filled with complaints and bug reports.

Symantec’s response was to enlist its most vocal detractors as beta testers for Symantec C++ 7.0 (myself included). The result is a solid C++ development environment with some of the best C++ debugging features on any platform.

[This review gives a brief overview of the product, but focuses mainly on the language itself. We will bring you a review of the TCL and Visual Architect in July. This review also only deals with the 68K product; the cross-compiler was not available for review as of this writing - Ed stb]

In addition to 6.0’s integrated debugger, scriptable project manager, support for external editors, integration with Apple’s SourceServer, and on-line help for the standard C and C++ libraries, Symantec C++ 7.0 also provides:

• Improved C and C++ compilers

• Universal headers, facilitating PowerPC compatible source

• Inspector, a heap analyzer tool

• Think Class Library (TCL) 2.0, a fully C++ framework with support for persistent objects, AppleEvents, and scripting

• Visual Architect, a visual interface builder for TCL

• AppleScript 1.1

• A 60-day money back guarantee

Symantec C++ 7.0 requires:

• 8 megabytes of RAM (12 megabytes recommended)

• System 7.0 or later in order to use all features - basic environment and source-level debugging supported under 6.0.7 and later

• A hard drive, 17 MB for a full install or about 7 MB for a fairly minimal install (essential tools, libraries, and headers)

Project Manager

Symantec 7.0’s Project Manager is much the same as in 6.0, with a few small changes. Besides the addition of color, the project window, shown in Figure 1, has remained unchanged. Source files are added to segments in the project window, and the Project Manager keeps track of which files’ object code needs updating. Segments can be named, collapsed, and expanded in the project window for segmentation control and simple source organization. The production of symbolic debugging information is controlled via toggling the bullet in the debug column. Projects can be included within other projects as libraries and hopped into by double clicking on the included project’s name. The integrated editor displays files selected from the project window and contains quick links to on-line reference information, header files, and the class browser.

One nice improvement is the New Project dialog shown in Figure 2. Any project placed in Symantec’s Project Models folder will appear in this dialog and serve as a stationary for new projects, retaining all of its original libraries and settings.

Figure 1 New project window and menus

A new AppleScript, which removes all files from a given segment of a project, has been provided. This alleviates a constant source of complaint for Symantec users: files have to be removed from a project one at a time. For large projects, this became quite tedious. This AppleScript, along with all others placed in Symantec’s AppleScripts folder, can now be executed through the new scripts menu seen at the far right in Figure 1.

Figure 2 Improved New Project dialog

Other improvements include:

• Code segments that are greater than 32K can be automatically resegmented (at file boundaries)

• The Find dialog remembers old search and replace strings

Class Browser

Symantec’s class browser now allows larger and more complex hierarchies to be viewed. Though by no means as full-featured as source browsing products such as Object Master, Symantec’s integrated browser provides an attractive, economical alternative. Each class is represented as a box, with base classes shown on the left and lines linking them to their subclasses on the right. Each box serves as a pop-up menu of methods through which corresponding source code can be obtained. Double-clicking on a box brings up the class’ header file. When using Symantec’s built-in editor, option-double clicking on any method name in the source will bring up the class browser and hilite all classes which define the method, as shown in Figure 3. I have found Symantec’s browser to be enormously helpful when exploring huge bodies of code and tangled class hierarchies.

Figure 3 Class Browser

Compiler Stability

The C++ compiler is drastically improved over the previous version in almost all respects. The parsing, standards compliance, code generation, and error recovery are significantly better than in 6.0.1. In the later stages of beta testing, the compiler passed over 99% of the MetaWare verification suite. Quoting the release notes, “all known code generation bugs have been fixed.” I have successfully compiled tens of thousands of lines of C++ code (including multiple inheritance, operator overloading, and nested classes) with Symantec C++, with only one workaround for the compiler. All other compilers that I’ve had the opportunity to try have required changes to my source code.

Multiple Inheritance

One area where the C++ compiler really shines is multiple inheritance. As Grady Booch states, “Multiple inheritance is like a parachute; you don’t need it very often, but when you do it is essential.”

Few compilers seem to get multiple inheritance right. Most CFront implementations prior to 3.0.2 and Symantec C++ 6.0.1 can produce bad code for cases as simple as the class hierarchy shown in Figure 4.

Figure 4 Multiple Inheritance Class Hierarchy

Table 1 shows the results of a sample program based on this hierarchy. In this test, a virtual function, Get(), is defined in classes A, B, and C. An instance of class CC is created and Get() is called through a pointer of type AA as follows:

/* 1 */
AA  *a = new CC;
a->Get();

The most derived version of Get(), C::Get(), should be called here, print the this pointer and return 5. It is evident from Table 1 that CFront 3.0.1 does not produce correct code here (a slightly different program causes a crash). The cause is also readily apparent: the this pointer has been miscalculated by CFront for C::Get().

Table 1 Sample Program Results

Variable Symantec C++ 7.0 CFront 3.0.1

this in C::C() af239e 1000b050

this in C::Get() af239e 1000b02c (wrong)

C::Get() 5 268480656 (wrong)

MPW C++ correctly generates code for this simple example, but fails on more complicated hierarchies. Symantec C++ 7.0 generates correct code for all multiple inheritance cases that I’ve tested, including projects with five generations of multiple inheritance (counting the hierarchy shown in Figure 4 as two). This has allowed me to #ifdef out dozens of workarounds needed with some other compilers.

Language Features

The C++ language has recently seen the development of several major features: templates, exception handling, and RTTI.

Templates, the oldest of these additions, allow the creation of general parameterized types and functions such as those shown here.

/* 2 */
template<class Type> class array  {
 public:
 Type  *a
 array( int size );
};
template<class T>  Type min( T a, T b);

Once defined templates can then be “instantiated” for a particular type by using them in source code as follows:

/* 3 */
array<float> v(4);
array<myClass>  c(10);
min(1,2);

C++ exception handling allows error handling code to be separated from normal execution code and packaged in a cleaner fashion. Unlike C’s longjmp, C++’s exceptions handling not only unwinds the stack, but also frees memory allocated from the stack, and calls destructors on class objects as needed. Exception handling also increases the utility of C++’s constructors by allowing failures within the constructors to be caught.

RTTI, or run-time-type-information, gives the ability to determine an object’s exact type at run time. Besides the obvious benefits of this, RTTI also allows safe, dynamic type casting between pointer types, including from virtual base classes to their derived classes, returning NULL if the cast is not possible.

Symantec C++ 7.0 adds no major language features to the compiler itself, though templates are now significantly more stable. Symantec still requires templates to be manually instantiated in source files such as the following (in addition to simply using them as shown above).

/* 4 */
// array<float>.cp: template instantiation file
#include "array.cp"
#pragma template array<float>
#pragma template operator<<(ostream&, array<float>&)
#pragma template_access public

The most recent major C++ language features, RTTI (run-time type information) and exception-handling, are not yet implemented in the Symantec C++ compiler. These features are implemented by macros and classes in the Think Class Library, however. This is an interim solution until compiler support for these features is added. When the compiler supports these features, the macros will be rewritten to use new compiler features so that no source changes will be required.

While code based on these TCL implementations is not portable like the standard C++ features (without writing some conversion macros), much of the functionality of these C++ features is present in the current TCL implementations for those who need it. Exception handling and RTTI do not require the entire mass of TCL, but rather just the Bedrock exception library, Exceptions.cp, and Exceptions.h. The following program demonstrates the syntax required to use exception handling and to declare a RTTI-aware class in Symantec C++ 7.0.

/* 5 */
#include <iostream.h>
#include <Exceptions.h>

class Overflow  TCL_EXCEPTION_CLASS
{
 public:
 TCL_DECLARE_CLASS
 Overflow(char A, double B, double C) {a=A; b=B; c=C;}
 char a;
 double b,c;
};

TCL_DEFINE_CLASS_M0(Overflow);

static void f(double x)  {
 throw_(Overflow('+', x, 3.45e107));
}

void main()
{
 // uncomment next line to skip Debugger() call when an exception is 
caught
 TCL_BREAK_ON_CATCH(false);
 try_  {// ARM p. 358, GREY p. 603
 cout << "example 2:" << endl;
 try_  {
 f(1.2);
 }
 catch_all_()  { // catch all exceptions
 // respond (partially) to exception
 cout << "exception partially handled" << endl;
 throw_same_();  // pass the exception to some other handler
 }
 end_try_
 }
 catch_all_()  {
 cout << 
 "rethrown exception caught again in outermost catch_all_()" 
 << endl;
 }
 end_try_
}

Symbolic Debugger

Symantec’s 7.0 debugger, which is identical to that in 6.0 with the exception of bug-fixes, is shown in Figure 5. Breakpoints are set by clicking on diamonds appearing along the edge of the source window. Buttons and keyboard equivalents provide easy source stepping. Data values can be displayed and modified by selecting them in the source window or typing in the Data window. Classes, structures, and arrays are displayed in individual named windows.

Figure 5 Symbolic Debugger

Symantec’s debugger provides a feature that is usually associated with interpreted environments: the ability to evaluate general C and C++ expressions, including method calls, preprocessor defines, and overloaded operators, on the fly. This ability is extremely useful when debugging complex code. Rather than adding lines into the program, recompiling and viewing the results, one can use Symantec’s debugger to evaluate expressions of interest at any time. The debugger also allows breakpoints to be conditional on the results of such expressions.

There are several limitations to this. Since the expressions are compiled and run on the fly, the expression must be something the compiler can understand in the current scope. Due to the dependence on the compiler, the debugger cannot be run apart from the Think Project Manager. Also, file writes and other “side effects” will not operate correctly when operating from such an expression, and the debugger will complain accordingly. The Data window in Figure 5 shows several uses of this general expression evaluation capability.

I have found the Symantec debugger to be extraordinarily helpful and have ported several projects to Symantec C++ from the SGI Iris mainly to take advantage of it. Its ability to evaluate source expressions on the fly is particularly useful.

THINK Inspector

The THINK Inspector is a completely new memory heap inspection tool. It is intended both for tracking down memory leaks and for quickly navigating through heap-based structures, such as linked-lists, which are generally somewhat tedious to traverse when debugging. Figure 6 shows the Inspector displaying objects of several class types.

Figure 6 THINK Inspector

The Inspector runs in conjunction with the debugger, and tracks the creation and deletion of all C++ class objects with virtual destructors. Inspector’s data is updated when the program stops in the debugger, operating via hooks in the new and delete operators (which must be added to user-defined new and delete operators if their objects are to be inspected).

The upper-left pane of each Inspector window is a list of classes, either alphabetical, or hierarchical, as shown here. Classes are selected from this list for inspection. Menu items allow either all classes with active instances or the next such class to be selected from this list.

The lower pane lists all the methods for any selected classes. Selecting a method will display its source in the debugger’s source window. This pane presents a handy alternative to the class browser while debugging. This and the upper left pane bear a great deal of similarity to Apple’s SourceBug, with the exception that the THINK Inspector understands C++ class inheritance.

The upper-right pane is the heart of the Inspector. It shows the current instances of any classes selected from the class list. Data members pointing to other heap-based objects can be expanded in a fashion similar to the Finder’s list views. Figure 6 shows a linked list being inspected. Note that though each object contains only a void pointer, the Inspector knows the actual class type of each object. If further viewing options or changes to data are desired, any portion of this pane can be sent to the debugger’s data window via a menu item for further manipulations. A menu item allows the source line where a selected instance was allocated to be displayed.

Multiple inspector windows can be active at any time, allowing instances of different classes to be tracked simultaneously in different windows. Each window’s panes are resizable and can be viewed in any text size and font. All window positions and preferences are saved between executions.

Memory leak tracking with the THINK Inspector is very easy. Simply set a breakpoint where you’d like to check up on memory usage and inspect the active instances of any classes of interest. By placing a breakpoint immediately before the end of the program and selecting a menu item, any class objects allocated throughout the entire execution that have not yet been deallocated can be quickly viewed.

Overall, the Inspector greatly enhances the debugging capabilities of Symantec C++ 7.0. I have found it very useful for checking for memory leaks and for traversing object pointer chains.

Symantec vs. the Competition

Until recently, Symantec’s only competition was MPW, which is significantly slower and harder to learn. Recently, however, Metrowerks introduced Code Warrior, a development release of a C, C++, and Pascal environment similar in many respects to Symantec’s.

The object size and compilation speed for the two environments are compared in Table 2 for both a small C project and a medium-sized C++ project. The timing shown is for the Metrowerks 68K code generator running on a 68K machine [Their PowerPC version of the 68K code generator was not timed for this comparison - Ed stb]. It appears that Symantec’s C compile times are slightly longer and the code produced is slightly larger than that produced by Metrowerks. Symantec’s C++ is much slower than Metrowerks’ C++, but Symantec C++ generates smaller code. Idid not determine how much of this speed difference is due to my source file arrangement (Symantec searches for files during each build while Metrowerks caches file locations). All results are for near/small code with Macsbug symbols off. The results varied somewhat given different compiler settings, file organization, and choice of code samples, but these results are generally representative.

Table 2 A brief time & size comparison

Symantec Metrowerks

Source Code C++ 7.0 Code Warrior DR/2

Time Size Time Size

C (size-optimized) 171s 124K 129s 116K

C++ (unoptimized) 954s 399K 468s 470K

C++ (size-optimized) 1701s 364K 479s 454K

In the battle for features, both environments have their advantages. Metrowerks boasts faster compile times and lower memory requirements for less than half the price; and both native 68K and PowerPC environments at $200 less than the price of Symantec’s C++/cross-compiler combination. Symantec’s advantages include its class browser, Visual Architect, heap Inspector, debugger source expression evaluation, and smaller object code. A brief feature comparison is given in Table 3.

Conclusions

Symantec C++ 7.0 is a big improvement over 6.0 and a good, full-featured environment. The C++ compiler itself, as well as almost every other component, is much more solid than in the 6.0.1 release, and is one of the most complete C++compilers available. The debugger’s ability to easily evaluate general C and C++ expressions on the fly is still unique on the Macintosh platform. The new THINK Inspector eases the burden of tracking heap-related problems. The inclusion and support of AppleScript, the updated TCL, and Universal Headers make this a well-rounded release. The biggest item missing is an available native PowerPC environment.

When considering purchasing Symantec C++ 7.0, two additional items should be considered:

• A C++ PowerPC cross-compiler is available for Symantec C++ for $100. Symantec views this as an interim solution until their native development system is ready for release. No release date has been announced for Symantec’s native tools.

• A free bug-fix upgrade from 6.0.1 to 7.0 versions of the C, C++, and Rez compilers, the debugger, and the project manager is available. All new components, libraries, and header files are available at an upgrade cost of $149 to Symantec C++ 6.0 users and a list price of $499 for new copies. Those who purchased version 6.0 on January 7, 1994 or later, can upgrade to 7.0 at no charge.

[One last thing: Symantec C++7.0 comes with 2000 pages of new, printed documentation - Ed stb] {Also, by popular demand, Symantec’s tools are available in the Mail Order Store. - Ed nst}