arket trends are a dominant factor in the evolution of IDEs. 15 years ago, syntax highlighting and extensive online help were all the rage; in the late 1990s, it was variables’ value examination by a mouse movement and auto-completion of member functions and arguments. Nowadays, multilingualism seems to be the hottest game in town. SlickEdit Studio v2 adopts this concept wholeheartedly with its support for numerous programming languages including C/C++, Java, Ada, C#, VB, FORTRAN, and others. Additional features include the ability to install Eclipse plug-ins, symbol referencing and lookup, key-bindings, and code beautifiers.

Leader of the Pack
The installation pack contained only a single CD. Compared to the 14 CDs of C++ BuilderX (of which only one was actually useful), it was a modest, though brave, start. The installation went smoothly?too smoothly in fact. As a multilingual IDE, SlickEdit automatically installs features and components that developers who stick to a single programming language don’t need. The result isn’t just a substantial waste of disk space but a longer installation time and constant background noise during code editing, debugging, and testing, as you will shortly see.

A Different Perspective
Creating a new project is a breeze with the New Project Wizard (shown in Figure 1): from the File menu?>New?>Project?> C/C++ Project.

SlickEdit can generate a source file containing main() with the indispensable #include followed by ‘using namespace std;’ already inside (see Figure 2).

Figure 1. Here’s the New Project Wizard.

?

Figure 2. This shows a generated source file.

I like this feature. While it’s not exactly a jaw-dropping, anything that saves programmers a few keystrokes is welcome. My enthusiasm didn’t last long, though. Building a project?perhaps the most common operation in any IDE?isn’t just a matter of a mouse click, in this case. Rather, you have to choose an appropriate perspective and click Build?>build.

“What on earth is a perspective?” you’re probably asking. In theory, perspectives are meant to facilitate viewing and working with projects. There’s a C/C++ Perspective, a Debug Perspective, a Resource Perspective, and so on. In practice, however, they are nothing but a source of confusion and complication. Honestly, doesn’t an IDE already know which programming language you’re currently using? Furthermore, what’s the use of an artificial split between Run and Debug, except for the automatic execution suspension at a program’s beginning?

I suspect that SlickEdit’s development team were enamored with their notion of perspective. That’s probably the reason why they wouldn’t jettison it during the product’s early development stages, although they certainly should have. The result is an unintuitive IDE that requires a lot of research in order to get basic operations done.

Standard Compliance
Those of you who have read my previous reviews know that I give ANSI/ISO compliance a high priority. SlickEdit was no exception even though it’s essentially a Windows GUI application wrapping good ol’ GCC and GDB. I therefore removed the dust from my standard-compliance test kit:

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;  

Figure 3. While debugging, your build errors show in the Resource Perspective.

GCC complained nosily about the missing ampersand in the second line. However, it accepted the default argument values in pointers to functions without any qualms. With the ‘-Wall’ and ‘-pedantic’ options turned on, I’d expected at least a warning. Although this isn’t SlickEdit’s fault but GCC’s, developers who need a highly-compliant compiler should take this into consideration.

Figure 4. In the debug dialog box, you choose either “Debug” or “Run.”

A Frustrating Experience
Compiling a program isn’t exactly a trivial task under SlickEdit as I’ve shown, but wait until you try to debug it! Imagine a typical debugging session under any GUI debugger you know. You load a project, press “debug” and the well-known keys “step”, “step into”, “watch” etc. become active. Not with SlickEdit, though. It rarely heeds developers’ intuitions. First, you need to search for the build output window. Heaven knows why, but the Resource Perspective is where you can view these in a human readable format (as shown in Figure 3).

Having fixed my source file and recompiled it, I was anxious to start my first debugging session at last. Guess what? For this purpose you have switch to Debug Perspective first. Then from the Run menu, choose either “Debug” or “Run” (see Figure 4).

Figure 5. SlickEdit’s spurious debug options.

As if the artificial and unnecessary distinction between Run and Debug isn’t confusing enough, each of these options is subdivided into three sub-options: “Run History”, “Run As”, and “Run” as well as “Debug History”, “Debug As”, and “Debug” To my surprise, The “Run As”/”Debug As” options enable you to do really stupid things like running a pure C++ console program as a Java application, a Java applet, a JUnit test, and a Runtime Workbench ?whatever this may be. Take a look at Figure 5 to see the debug options.

This would make some sense in a multilingual project. However, in a 100 percent pure C++ project, all that Java jazz doesn’t just get in the way?it’s a lurking trap. After a 12 hour working day, a weary developer could well hit the wrong option. I’m sorry to say this, but even my el cheapo ROM burner employs human engineering rules more rigorously.Tech Support Blues
Having learned the hard way what the correct sequence of operations is for debugging a C++ program, I still wasn’t able to get things going. Ominous error messages and mysterious crashes nipped every debugging session in its bud. There was no escape from contacting SlickEdit’s tech support. Trust me, if there’s one thing reviewers hate more than contacting tech support, it’s receiving machine generated replies that contain absolutely nothing helpful. And machine generated replies is exactly what I got. Only a couple of days later a human reply arrived. At last, I was able to debug my program! Figure 6 shows a typical debugging session.

Figure 6. A typical debugging session.

Sadly, my debugging experience was less than exhilarating. Features that have become a de-facto standard in other IDEs?such as examining a variable’s value by passing a mouse over it or stepping into runtime libraries’ sources?are noticeably missing. I realize now how much I’ve been taking C++ BuilderX for granted!

SlickEdit Studio Needs Polishing
SlickEdit offers many promising features, like multilingual editors and a high degree of customizability. Unfortunately, in terms of human engineering, it’s a disappointment. Not only does it confuse you with the dubious notion of perspectives, it also insists on doing things in the most unintuitive manner. Even worse, the cluttered-up interfaces and the excess Java baggage that keeps getting in your way are a royal annoyance. My estimate is that 60 percent of the menus and dialog boxes contain irrelevant options for most users. This product is therefore best described as a diamond in the rough&#151one that still needs extensive polishing. On the positive side, SlickEdit manages to provide a GUI wrapping on top of traditional command line products that have a well-established reputation. As such, GCC and GDB aficionados will benefit from the GUI facelift of their favorite products.