Customization The Highlight of Cbuilderx Release
NEW C IDE from Borland Builds on the efficiency of its Predecessor, But existing builder users Should Be Prepared for Some Glitches in The Learning Curve.
By Danny Kalevnovember 11, 2003
script>
ive years ago, I reviewed Borland's C Builder 4.0 and I was so impressed with it that I have used it as my C IDE ever since! So I jumped at the chance to review this latest release. C BuilderX is a multiplatform IDE for building C applications that can be deployed on various target platforms: Windows, Solaris, Linux, and Symbian-powered mobile devices Additionally, it offers an unparalleled degree of customizability, enabling you to choose the underlying compiler, linker, and debugger according to your preferences and. Target Platform.
InstallationDespite the fact that C BuilderX pack contains no less than 14 CDs, the installation process went fast and smoothly. Of all the 14 CDs, only the one containing the C BuilderX core files is essential. The remaining CDs contain optional compilers, commercial database libraries , performance tuning tools, and other goodies. I decided to stick to the basic configuration and add more components later, should the need arise. The unavoidable registration process was also fast, although the pestilential habit of forcing it on customers should be discouraged.
C BuilderX's default look and feel was rather disappointing. If anything, it looked like a mid 1990s AWT-based applet, with those sluggish buttons and menus, blotchy fonts, and a gloomy gray background (Figure 1 shows the default C BuilderX user interface) . fortunately, I soon learned that customizability is C BuilderX's strongest feature. You can choose between four different "look and feel" settings, including Emacs, Motif, and Windows. Naturally, I chose the Windows look and feel (Figure 2). At Last, I Was Ready To Build My First Application.figure 1: this is The Default C Builderx User Interface. Figure 2: The Windows Look and Feel.
Test Drive
Although C Builderx Retains Many Of C Builder's Characteristics, There Are Quite a Few Changes. For Starters, The Class View Has Been Significantly Improved
Figure 3). It now lists every macro, #include file (recursively!), Enum type, function, and class member. There are other welcome enhancements besides that. Customizability, as noted previously, is the name of the game. Not only does C BuilderX allow you to choose from five different keymaps including Emacs, Visual Studio, and Macintosh CodeWarrior, you may even define your own keys. Visual C developers, for instance, can feel at home by switching to Visual Studio's debugger keymap. Nifty, ISN 'ket
Figure 3 :. The new and improduved classview.
Nonetheless, some of the changes are less enthralling. C Builder lets you edit a source file during a debugging session. It immediately recognizes any changes and kindly asks you whether it should rebuild the current project and launch a new debugging session. Consequently, I developed a foolhardy habit of fixing source files during debugging instead of waiting patiently for the program's orderly exit. While this can be perilous, most code fixes are small and frequent so why waste precious time? Alas, C BuilderX is not as lenient as C Builder . It locks all source files during debugging. If you want to edit any of them you have to wait patiently for the debugging session's graceful termination or abort it using the "reset program" key. I was not ready to give up so easily, THOUGH. a little poking about it
Standard DeviationOne of my main concerns when choosing a C IDE is ANSI / ISO compliance. In this regard, C Builder circa 1998 was a treat to work with. Its core language compliance was close to 100 percent-a rarity in those days. A lot has changed since then, however. Microsoft's promise to bring Visual C .NET to full ANSI / ISO compliance has become a reality. Likewise, GCC and Sun's Forté have improved considerably. While a full ANSI / ISO compliance test is beyond the scope of this review, I tested some of the minor nits that vexed me in C Builder. The first test checks whether C BuilderX allows default argument values in pointers to functions and pointers to member functions. According to the C standard, they're verboten.Here's the Relevant Code Snippets Used in this test:
Void (* pf) (int x = 81); // default argument not allowed here
// missing & before a :: g; default argument not unloaded here
INT (a :: * pmf) (int x = 51) = a :: g;
C BuilderX compiled the code blissfully Do not get me wrong:.. Several compilers have allowed default argument values in pointers to functions for years Therefore, this is not truly a bug but rather a "nonstandard extension." Still, I would expect to receive a diagnostic message in this case. Taking a member function's address without an ampersand is even worse. Yet C BuilderX did not issue a warning about this either. For cross-platform developers this might be a problem since some compilers would reject this Code altogether.
My Second Test Checks The Order of Exception Handlers. I buy The Following Test Program:
Class base {};
Class Derived1: Public Base {};
Class Derived2: public base {}; int main ()
{
Try
{
Throw derived2 (); // shop activate the second handler
}
Catch (Derived1 & D) // Handle Derived1 Exception
{
}
Catch (base & b) // Handle Base and Derived2
{// Throw Statement Above Should Transfer Control
} // To this block
Catch (...) // Any Other Exception
{
} // alas, the debugger jumps to this line
Return 0;
}
When the Throw Statement In The Try Block Executes, The Debugger Mistakenly Points To The Wrong Handler (See
Figure 4) instead of entering the second catch block. This is very misleading. I remember this bug had me tearing my hair out when I first encountered it in C Builder. It persists in C BuilderX. By the way, this is a debugger bug The Generated Assembly Code Seems To Be Correct.
Figure 4. When The Throw Statement in The Try Block Executes, The Debugger Mistakenly Points To The Wrong Handler.
A Tale of Two LibrariesC Builder used Rogue Wave's STL which was pretty antiquated and cluttered up. I was therefore glad to discover that BuilderX had migrated to STLport's implementation instead. In many respects, STLport is cleaner and more standard-compliant. Alas, my elation was short-lived. I noticed that identical programs executed under both C Builder and BuilderX showed a significant difference in execution speed. Under C Builder they were 30 percent faster on average. Knowing that the underlying compiler and linker of both IDEs were essentially the same I suspected That The Culprit Was Stlport. To Corroborate this, I Wrote Another Test Program That Didn't Use Any Standard Library Components. This Time, Execution Speed Was Virtually Identical. It was stlport.
Figure 5:.. The Project Properties.Mixed EmotionsC BuilderX's claim to fame is its multiplatform development capabilities I wanted to find out how realistic the promise of "write once, deploy anywhere" (! Not copyrighted yet) was I decided to build my project with Intel C 7.1 instead of the default Borland bCC32 compiler I installed Intel's CD (included in the package) The installation dialog box blurted an ominous warning:... it could not locate Visual C 6.0 or higher installed on my machine You're probably wondering what Visual C has to do with Borland's IDE. So did I. It appears that a separately licensed and installed version of Microsoft Visual Studio C 6 or Visual Studio.NET are necessary for using Intel's compiler under C BuilderX. I ignored this warning and proceeded according to the original plan. Everything seemed to be working smoothly until I hit the "build project" key (see Figure 5 for the project properties). C BuilderX's patience ended here. A noisy error me .
Figure 6: Here's a list of code templates supported by The Builderx Editor.
Editor's CornerThe C BuilderX editor also brings novel features-including user-adjustable code templates for class declarations, for-loops, functions, try and catch blocks, and so on (see Figure 6 for a list). In addition, it allows you choose the font, color setting, and default indentation. Be careful when changing the editor's font, though. I mistakenly chose Lucinda Console. It took me awhile to figure out why the editor would not let me erase or insert characters in the right place. Instead, it insisted on deleting one character before the cursor's position or one after it Sometimes it erratically jumped past {,} or;.. signs I tried to disable the "smart indent options" and "smart key option", to no avail. At a certain point I even found myself editing source files in good old C Builder and pasting them back into BuilderX's editor (what an incredible way to increase developers' productivity!) until it hit me: the Lucinda Console font was causing the whammy Setting! The Editor To Courier New Immediately Solved The Problem.