IDE Review 96
Volume Number: 12
Issue Number: 12
Column Tag: Development Environments
Choosing Your C/C++ IDE 
How well do the latest Metrowerks and Symantec C/C++ IDEs stand up to
each other?
By Will Iverson, Apple Computer Inc.
This article compares two mainstream Macintosh IDEs, Metrowerks CodeWarrior
10 (CW10) and Symantec C++ for Power Macintosh 8.0 Release 5 (sometimes
referred to as SC++ 8.5). A closing section will look at alternative environments such
as MPW and VIP-C, but the focus here is on the now “traditional”
editor-project-debugger suite of tools made standard by the THINK tools.
The goal is not to instruct the reader as to which tool to buy, but rather to
illustrate the strengths and weaknesses of both environments.
The most striking thing about these two editors is not the differences, but rather
the similarities. Even the default colors are nearly identical. Some subtle differences
emerge when deeply scratching the editors, but the majority of the differences are
minor interface changes. Both environments are scriptable and include a “Scripts”
menu that includes several useful scripts (CW contains 7, SC++ contains over 30).
However, to get the most of the scripts some knowledge of AppleScript or Frontier
would be quite helpful.
Figure 1. CodeWarrior editor.
Figure 2. Symantec Editor.
Both environments support source code highlighting, horizontal and vertical
split panes, and “markers” allowing you to mark locations in your code. SC++ tends to
be a bit smarter about coloring strings and allowing for multiple fonts, styles and
colors, but CW is more flexible about configuring which words to highlight.
A very interesting and rather curious development is the addition of Apple Guide
support to both products. Evaluating the effectiveness of these Apple Guides is
exceedingly difficult for this (somewhat jaded) writer. The step-by-step
walk-through of such things as “how to build a C++ project” is too grating to bear,
but the usefulness to new programmers is potentially quite great. I would be interested
to hear of the effectiveness of these Apple Guides from new programmers.
Both Find dialogs offer virtually identical functionality, packaged in completely
different interfaces. The CW Find dialog supports “sets” that allow you to quickly
switch between multiple groups of files. Metrowerks recommends creating a set of
library export symbols to quickly figure out which library to import when unresolved
link errors arise. They provide the export symbols files to search.
This is not to say that the two environments are identical. Symantec features a
KeyBinding utility, which allows you to re-map all keystrokes (such as to match the
Emacs suite). Metrowerks allows you to edit errors in the same window in which the
message appears. Nice for minor syntax errors. Metrowerks includes a toolbar, which
looks whizzy in demos but basically just takes up screen space. Although Metrowerks
offers the option of removing it, you then lose status messages during builds and links.
[You can remove all the buttons by Command-Control-clicking each one. The toolbar
then collapses to only the status bar. - Ed. esg.]
Browsers
As Figures 3, 4 and 5 show, the CodeWarrior browser is much more rich than
the browser currently offered by the Symantec C++ environment. This is ironic, since
the Symantec browser was available nearly a year prior to the first sluggish CW
browser. Symantec’s browser in Café, their Java development environment, offers
quite a bit of additional functionality compared to their C++ environment. Symantec
insists that there will be a release 6 of SC++ that will bring the C++ browser to
parity with the Café browser, although they were unable to specify when.
For those unfamiliar with the class browser, the concept is simple. During a
parse phase (combined into the compile for both environments) the project manager
builds a database of symbols, including class table information. The environment
presents this information in the form of a “browser,” allowing the user to navigate
classes and their functions more easily. Browsers are typically more useful for C++
users than C users, although the CodeWarrior environment makes some gesture toward
C users with their “catalog” concept.
Perhaps the most interesting element of the CW environment is the integration of
the browser into the base editor. Certain words flagged in the browser database are
automatically highlighted, and by clicking and holding the mouse on these words it
presents the user with a variety of context-sensitive menus. Options include finding
the definition, inserting a template, finding (through hierarchical menus) member
function declarations and definitions, and finding all implementations of the selected
keyword.
Figure 3. CodeWarrior graphical browser.
Figure 4. CodeWarrior class browser.
Figure 5. Symantec class browser.
Project Management
What the Symantec environment lacks in browser bells, it makes up for in
Project Management frills. Both environments include basics such as status, touching
files, etc. Both support dropping files from the Finder, but the Symantec environment
also allows dragging files out of the environment and into other applications, allowing
for convenient drop-launching.
Figure 6. CodeWarrior Project Manager.
Figure 7. Symantec Project Manager.
The Symantec environment supports “untouching” files, useful when you have
modified a comment in a header and want to avoid a complete rebuild. The Symantec
environment supports nested folders and projects (which can be set to rebuild
automatically) and integrated Projector source control, including database creation,
mounting, setting, and check in and check out. The Symantec environment allows you to
open a text file without a project file being open, and also allows you to open multiple
projects. Multiple projects are especially nice when grabbing libraries or
synchronizing with another project.
Compilers
As you can see from the numbers below, the CodeWarrior environment is
considerably snappier than the Symantec environment for large builds. Part of this is
no doubt due to the more sophisticated project management system underlying the
Symantec environment. Such features as internal threading - allowing you to continue
editing source files during a build, no doubt contributes to the build time.
Build Speed
Build time
CW 12 seconds
Symantec 25 seconds
Time to build and link 13 source files (a mix of C/C++) and five libraries on a
7500/100 (PowerPC 601), 64MB of RAM, 256K L2 cache, with the default memory
allocations for each environment, on System 7.5.3 Revision 2. No optimizations,
default precompiled MacHeaders, and default Macintosh C++ application project
models.
Turnaround Speed
CW 4 seconds
Symantec 4 seconds
Time to make a single, trivial change to a source file, hit run, and be running the
application.
It is beyond the scope of this article to cover the quality of code generated by
these compilers. You can pick and choose among the dozens of benchmarks available to
determine the “best” results. Put another way - if I wanted to show you that my
compiler is faster, give me a day and I’ll have a dozen performance tests to show you
why it’s the fastest, even if I had to go through three dozen tests to find them.
Generally speaking, the speed and robustness of both compilers are quite
reasonable. If you are truly obsessed with speed, you can check out the Motorola
compiler and Apple’s MrC, both of which are available as drop-ins to both
environments. If you would like to see some in depth coverage on the topic of Macintosh
PowerPC compiler code generation, I strongly encourage you to check out back issues
of Game Developer Magazine. For more information, check http://www.gdmag.com/,
specifically the June/July 1996 issue.
Finally, it is worth mentioning that the CodeWarrior compiler supports
Direct-To-SOM. Those of you interested in OpenDoc and component technology should
pay attention to further developments in this arena.
At first blush, the two debuggers appear quite similar. Both have simple VCR
style controls, stack crawl displays with turn down triangles to view variables, and
source views with marks to show locations at which to set breakpoints. Beyond the
superficial comparison, differences begin to emerge.
Figure 8. CodeWarrior Debugger.
CodeWarrior approaches debugging from a shotgun perspective. Want a feature?
It’s here, including memory and register displays, double-clicking a variable to
display it in a memory window, a breakpoint summary window, watchpoints, MacsBug
dcmds (to switch from MacsBug to the CW Debugger) and more.
Figure 9. Symantec Debugger.
The Symantec debugger offers a much more sparse environment, centered largely
on the “Data” view window, which allows a user to enter an expression and have it
evaluated on the fly. If you have a need, the Symantec debugger will force you to
wrestle with the Data window. The Symantec debugger does have a few nice touches,
such as the ability to view the source in the same fonts and styles specified by the
editor. Your code looks the same in both places.
Both debuggers are separate applications, requiring the user to wait while they
launch for the first time. Symantec has in development a debugger that includes many
of the features of the CodeWarrior environment, including memory and register
displays. It is scheduled for Release 6 of the environment.
It is beyond the scope of this article to provide an in-depth technical review of
the two frameworks, Metrowerks’ PowerPlant and Symantec’s THINK Class Library.
PowerPlant includes Constructor, a tool for generating graphical interfaces (driven
entirely from a data perspective), and Symantec provides Visual Architect, a similar
tool that also generates source code (although only for graphical interfaces - no Delphi
here).
I suggest that prospective users of either framework do their homework before
embarking on a project. Consult the back of this magazine for many books on
developing with either framework, and pick up a book on each. Skim through them, and
decide for yourself which seems more intuitive.
Requests
Both environments do basically the same things, with subtle differences in the
way they operate and their feature sets. Here are some needed features that seemed to
be logical evolutionary steps.
• Better error handling. Frequently the error includes a suggestion on how to fix it
- why not offer a “just do it” button?
• Smarter linkers/linker errors. If the linker gets an unresolved symbol error,
why not offer to search the system path to find and suggest a library with the
relevant symbol?
• Better 68K/PowerPC integration. A simple button in the corner should allow me
to flip between 68K and PowerPC builds from a single project file.
• Breakpoints in the editor.
• An “Instant” capability allowing me to type in small pieces of code and click an
“execute” button.
• Specifically for Metrowerks: support removing the status bar and bringing it
back during a build. Both environments could and should offer graphical bars that
are visible from a distance (like a Finder copy).
• Collapsible code (a hierarchical outline display of loops, functions, and such).
• Smarter build management - if I’ve only edited a comment in a header do not
trigger a complete rebuild.
Alternatives
One of the leading contenders for an “alternative” C development environment is
Mainstay’s VIP-C. As you can see from Figure 10, the VIP-C editor offers many
innovations. Clicking the black triangle next to the insertion point allows you to select
from a palette of functions to embed any number of routines. The box on top of the
source code is the function template guide, which allows you to easily tab through the
parameters for a function, quite useful for functions with long parameter lists. The
mini-windows are not merely summaries - this is where and how they are declared.
Figure 10. VIP-C editor.
The flowcharting feature is quite useful to ensure that the logical flow of a
program is correct. Bugs tend to fall into syntax, logical, and functional categories. The
compiler typically catches Syntax errors, and VIP-C’s error reporting is not
significantly more powerful; although, it does help provide easy mechanisms for
defining new variables. The interpreter catches functional bugs, and the flowchart
provides the best stab yet at beginning to provide a solution for logical bugs.
Figure 11. VIP-C Project Manager.
The primary difference between VIP-C and the two mainstream vendors is the
fundamental difference in their approach to a project. As you can see from Figure 11,
VIP-C is based on the concept of routines, not files. This apparently minor difference
abstracts from the developer the hassles of dealing with .c and .h files, making for a
much more pleasurable development experience.
Unfortunately VIP-C supports only C, not C++, and Mainstay has made clear
their plans not to support C++ in the future. Those of you worried about migration
paths and performance may be intrigued to know that VIP-C offers an export to
CodeWarrior, including all of the source code. VIP-C may not be for everyone, but it
provides a very enjoyable alternative with an easy migration path.
There are other alternatives, the most prominent of which is MPW. Macintosh
Programmer’s Workshop is Apple’s entry into the field, and it is curiously the least
“Mac-like” of all of the environments. A command line tool at heart, MPW will appeal
most to UNIX and DOS refugees. It is also quite useful for complex and sophisticated
builds; something large houses encountering limitations in other environments should
keep in mind. For more information on MPW, MrC, and other Apple favorites such as
the vital ResEdit and MacsBug, check out http://www.devtools.apple.com/.
Conclusion
The Macintosh C/C++ market is more fertile than many think. Metrowerks is the
current market leader, but time has shown that the market can be fickle. The current
suites of tools are adequate, but leave quite a bit of room for improvement. In the
estimation of this writer, the larger question is not the battle between environments,
but rather between C++ and Java. I would be interested in hearing feedback and the
experiences of other developers pursing all of these paths. Drop a note to
iverson@aol.com.