IDE Review 96
|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.]
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. Symantecs 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.
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.
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.
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.
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 Ill have a dozen performance tests to show you why its 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 Apples 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? Its 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 Symantecs 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.
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 Ive only edited a comment in a header do not trigger a complete rebuild.
One of the leading contenders for an alternative C development environment is Mainstays 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-Cs 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 Programmers Workshop is Apples 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/.
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 firstname.lastname@example.org.