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 Kalev
November 11, 2003
Installation
Despite 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't it?
Figure 3:. The new and improved 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 isn't 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 wasn't ready to give up so easily, though. A little poking about revealed the secret handshake, namely disabling the "Editor files are read-only during debugging" option under Project Properties—>Debug. Hallelujah!
Standard Deviation
One 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 allowed here
int (A::*pmf)(int x=51)=A::g;
C++ BuilderX compiled the code blissfully. Don't get me wrong: several compilers have allowed default argument values in pointers to functions for years. Therefore, this isn't 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 didn't 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 ordering of exception handlers. I used the following test program:
class Base{};
class Derived1: public Base{};
class Derived2: public Base{};
int main()
{
try
{
throw Derived2(); //should 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 Libraries
C++ 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 Emotions
C++ 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 couldn't 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 message "please verify that the build tool is installed and available to the IDE nipped my vision of multiplatform development in the bud.
Figure 6: Here's a list of code templates supported by the BuilderX Editor.
Editor's Corner
The 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 wouldn't 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.
Final Judgement
C++ BuilderX offers an unrivaled level of customizability. How many other IDEs allow you to adjust the default keymap, look and feel, or just about anything else so easily? In terms of stability, it's a marked improvement over C++ Builder, although it has crashed a couple of times. As for the promise of multiplatform development under a single IDE, it has yet to be fulfilled. Although this product is an important step towards this goal, you still need a separate license for Visual Studio in order to use Intel's C++ 7.1 compiler and a Professional version of Microsoft Visual Studio if you wish to use Intel's optimizations. Mobile development is also confined to Windows in this release. Apart from minor glitches that will be fixed soon hopefully, C++ BuilderX is a fine choice for mainstream C++ application development.
