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 wayit'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.